>>> If Firebird can do this without having to define the tables "locally", I
>>> think it's better.
>> Well... as you see, we would need to find a solution for SQLDA thing.
>> The issue that we're having with our 31-character limit on the object
>> identifiers is directly related to this, since if we start passing
>> 128-byte-long table names, we can easy cause AV in client applications.
>> Same applies to extending XSQLVAR... we can't simply add new field to it
>> without changing the XSQLDA version, but if we do - we have to be sure
>> that every component suite is capable of supporting this.
>
> Right, that's quite the change.
>
> Why not add this while at the same time allowing for 128 byte identifiers
> in Firebird databases as well?

Because such change would require coordinated release of the database
engine and all drivers that we have (Jaybird, .Net provider, ODBC-JDBC)
and third-party providers (IBPP, PHP, FIBPlus, IBObjects) to make the
feature usable everywhere and not distract customers (what if FIBPlus
will support it, while IBObject won't?). In my opiniton we're simply not
yet ready for such thing. Too big change, I think.

> Well, reason I'm asking is because of compile time errors, really. Would
> the engine understand the @ syntax and ignore anything metadata related
> coming from that?

If you mean technically - well, you have to change parser.y to support
such syntax. Also I do not think that engine should ignore anything here
too - in the isc_dsql_prepare it has to decompose the SQL statement,
talk to remote engine, check if everything is ok and execute it. The
PSQL case is really hard, as it was already pointed out... we have only
one choice here - defer the check to runtime. That is why I like the
CREATE TABLE extension - the engine can do some dependency checking as
well. And distributed dependency checking in "Firebird-only" case might
be concentrated only in DDL - prohibit any structural change to the
table unless the external dependency on it exists.

Roman