Re: Deprecation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Deprecation
Дата
Msg-id 9261.1255802278@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Deprecation  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Deprecation  (Bruce Momjian <bruce@momjian.us>)
Re: Deprecation  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Reworks for Access Control facilities (r2363)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Deprecation