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
--
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 |