Re: Deprecation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deprecation
Date: 2009-10-17 17:57:58
Message-ID: 9261.1255802278@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-10-17 18:10:08 Re: Deprecation
Previous Message Heikki Linnakangas 2009-10-17 13:53:26 Re: Reworks for Access Control facilities (r2363)