I always wondered if there was a way to get the extra features via a cheat.

Currently, the API and all the various code tools understand the limited 31
byte object name identifiers.
For all intents and purposes, the SQL object name is a primary key. BUT,
why should it be? It could be a surrogate key for the next version or so.
If it is a auto-generated surrogate key and all we did was change the way
the parser looks up table names, then we could shoe-horn in a short term
fix.

For example, Lets look at RDB$RELATIONS

Right now, we have RDB$RELATION_NAME as Char(31) Unicode_FSS

IF we added two new fields

RDB$SCHEMA_NAME as Char(255) Unicode FSS
RDB$SQL_OBJECT_NAME as Char(255) Unicode FSS

Then when the parser looks up a table, it does so by addressing the two new
fields, but, when passing values around internally, it uses
RDB$RELATION_NAME.

If the table name needs to be passed across the wire using the existing
API's, it uses RDB$RELATION_NAME but when extracts/sql/dml ie user
interface/parser work is to be done, the system surfaces the two new fields.

Now, some nuances may be needed to get it to cover the basic needs, but, for
all intents and purposes, it should work well.

An internal function could be used to generate the Surrogate key and you may
want to move the RDB$ tables to a new name while surfacing the old structure
with a series of views, but, that is stuff we have all been doing for years.

From what I am proposing, the majority of the work is in the parser.

Just 2c from the peanut gallery from a guy who has not looked at the API.

best regards

Dalton


If the RDB$RELATION

On 27 April 2010 13:12, Ann W. Harrison <aharrison@...> wrote:

>
>
> Roman Rokytskyy wrote:
> >> Would you care to clarify that? I'd really like to know why longer
> >> names cannot be done well.
> >
> > Maybe because you would need to extend the XSQLVAR structure to include
> > schema name variable. Which is not backwards compatible.
> >
>
> One could maintain the existing DSQL interface for applications that
> don't use schemas or long names and design a more flexible and forward
> looking version for V3. Or even just add a new version of the XSQLVAR.
>
> Best regards,
>
> Ann
>
>
>


[Non-text portions of this message have been removed]