Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Dec 22, 2024 at 12:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In particular, in a situation where we're trying to show a plan for
>> a query with inlined views, EXPLAIN would probably have to have code
>> to unique-ify the names anyway --- there's no way we're going to make
>> these nonce names globally unique, so the view(s) might contain names
>> that conflict with each other or the outer query.
> When you say "there's no way we're going to make these nonce names
> globally unique," is that because you think it would be too costly
> from a performance perspective (which was my concern) or that you
> think it's flat-out impossible for some reason (which doesn't seem to
> me to be true)?
Global uniqueness across the database (not single queries) would be
needed to prevent cases where different views use the same generated
names. The only way I can see to do that without nasty performance
costs is to use something like an OID counter. Which would mean
that rather than nice names like "union_1", "union_2", etc, you'd
soon be looking at "union_5846926". I don't think anyone would
find that to be an improvement on what we're doing now.
> If we had global uniqueness, or even per-subquery-level uniqueness,
> this would sort itself out somewhat nicely, I think. We would just end
> up with select_1 and select_2 or union_1 and union_2 or something like
> that, and I think that would be strictly better than the status quo
> where we do sometimes generate *SELECT* %d, but also sometimes just
> *SELECT* and other times unnamed_subquery, and also only ever *VALUES*
> and not *VALUES* %d.
I'll concede that it'd be nicer. But I'm not convinced it'd be enough
nicer to justify the costs of changing. We've been doing it this way
for a long time, and AFAIR you're the first to complain about it.
regards, tom lane
