From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Deprecation |
Date: | 2009-10-17 18:10:08 |
Message-ID: | 200910171810.n9HIA8l18855@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> However, if the columnref looks like "x.y" where x happens to
> >> match some table in the database (and not in the query) that doesn't
> >> have a column y, the implicit-RTE code will have already modified the
> >> querytree before finding out that column y doesn't exist.
>
> > Hm, so if you do nothing then really the only thing that doesn't work
> > is if you have add_missing_from then plpgsql record variables wouldn't
> > work when you tried to reference their columns?
>
> "Do nothing" isn't the right phrase here --- it would take a great deal
> of work and ugly, hard-to-maintain code to get it to work even that badly.
> The code paths in transformColumnRef are fairly messy already :-(.
> Getting rid of add_missing_from would definitely make it easier to
> refactor to support hooks for external variable sources.
>
> The approach I had been thinking about proposing, before David piped up
> with his modest proposal, was to have external variables take precedence
> over implicit RTEs --- ie, we'd call the hook *before* trying the
> add_missing_from case. But that seems pretty weird, and it'd still be
> messy to program. What it would mainly accomplish is to avoid the extra
> lock hazard.
Sounds like a good reason to remove add_missing_from in 8.5.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2009-10-17 18:47:31 | Re: Deprecation |
Previous Message | Tom Lane | 2009-10-17 17:57:58 | Re: Deprecation |