Re: pre-MED

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pre-MED
Дата
Msg-id 26476.1225724556@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pre-MED  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: pre-MED  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> David Fetter wrote:
>> However, there are little lacun� like this:
>> 
>> SELECT * FROM show_qual() s(a)
>> WHERE A NOT IN (
>> SELECT 'foo' UNION ALL SELECT 'bar'
>> );
>> a
>> ------------------------
>> (NOT (hashed subplan))

> This little lacuna seems to say that if you pass the wrong query to
> dblink, it will fail to work, possibly with a very obscure error
> message; it will be very difficult to debug, and also very difficult (if
> not impossible) to workaround.

Yeah.  The problem here is that the portions of ruleutils.c that deal
with executable plan trees (as opposed to parser output) have never been
designed or intended to do more than support EXPLAIN --- which means
that "human readable" has been considered not only sufficient but more
important than "100% correct and mechanically re-parseable".  The
proposed patch raises the bar enormously.  I'm not even real sure what
all the issues would be, but I'm pretty sure that subplans are just the
tip of the iceberg.  Occurrences of Params ($n) would definitely be
another failure case, and I also wonder what would happen with join
clauses (containing references to the outer side of a join).
        regards, tom lane


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: don't use MAKE_PTR/OFFSET for shmem pointers
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pre-MED