> In converting an application from FB 1.5.x to 2.0 I am eliminating all
> aliases from my client code because of the new alias rule that
> eliminates ambiguities.

Personally I see that as throwing the baby out with the bathwater. You
would be better off imo to use aliases for everything as it allows you
if need be to rejoin to the same table multiple times. For example,
you may have a table of customers and a referrals table, and you may
want to list all customers and which customers referred them etc.

"if an alias for a table is used it must be

> used always in place of the table name." Its straightforward and safe.
>
> In the FB2 RC1 release notes under PSQL this rule is not stated or I
> have missed it. I suppose PSQL is SQL? The ambuguities of SQL can be
> carried to PSQL.
>
> Does the new table alias rule apply to PSQL? I assume it does but
> welcome some better insight.

PSQL is the language used in stored procedures and triggers. It
includes the ability to run SQL, as well as if statements and loops etc.

So they are not the same, but obviously if it is considered ambiguous
in SQL, then the same statement executed inside a stored procedure
should also be considered ambiguous.

I find the rule annoying sometimes to be honest. When there is no
ambiguity as to which field is being referenced, I do not see why it
should complain (although the standard says it should), however it is
also bad practice. Someone in the future may introduce a field with
the same name into another table you have joined to, thus making your
SQL statement ambiguous sometime in the future.

Adam