Re: Make subquery alias optional in FROM clause

From: Nico Williams <nico(at)cryptonector(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make subquery alias optional in FROM clause
Date: 2017-02-23 16:30:20
Message-ID: 20170223163019.GC30233@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 23, 2017 at 10:37:16AM +0100, Bernd Helmle wrote:
> 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.

There's another option:

* Gensym an alias name, and if the compilation fails with that alias
name as a conflict, try again with a new gensym'ed name.

> * Don't force/generate an alias at all.

That seems like a lot of work.

Nico
--

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-02-23 16:30:50 Report the number of skipped frozen pages by manual VACUUM
Previous Message Simon Riggs 2017-02-23 16:30:03 Re: Documentation improvements for partitioning