Bernd Helmle <maili...@oopsware.de> writes:
> Right, i'm going to give it a try then. Currently i see these options:
> * Validate any generated alias against a list of explicit alias names.
> This means we have to collect explicit alias names in, say a hashtable,
> and validate a generated name against potential collisions and retry.
TBH I think a hashtable is overkill. You could just run through the FROM
clause and see what's there (compare what happens in ruleutils.c when it
has to invent an alias). The difficulty is not so much with time taken
as that it's not very clear how to manage things when the querytree is
only half-transformed. You don't really want this code having to deal
with both transformed and untransformed querytrees, much less knowing
which parts are where.
Maybe the best answer is to not do it immediately when transforming the
subselect's RTE, but to go back after we've finished transforming the
entire FROM clause and add aliases to any RTEs that lack them. I think
probably at that point you could just examine the RTE list and not worry
about any jointree data structures at all. It might be worth adding a
flag to ParseState to remember whether any aliases require assignment, so
that you could skip looking in the standard case.
> * Don't force/generate an alias at all.
> I've no idea for this yet and Tom already was concerned what this might
> break. There are several places in the transform phase where the
> refnames are required (e.g. isLockedRefname()).
Yeah. This would be cleaner in some sense but also a lot more delicate.
Not sure it's worth the trouble.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
