Am Mittwoch, den 22.02.2017, 22:17 -0500 schrieb Tom Lane:
> [ shrug... ] Well, I won't resist this hard as long as it's done
> competently, which to me means "the subquery name doesn't conflict
> with
> anything else". Not "it doesn't conflict unless you're unlucky
> enough
> to have used the same name elsewhere". There are a couple ways we
> could
> achieve that result, but the submitted patch fails to.
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.
Or better, generate the name in a way that doesn't produce a collision
with this list.
* 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()).
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
