Re: pre-MED - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pre-MED
Date
Msg-id 26476.1225724556@sss.pgh.pa.us
Whole thread Raw
In response to Re: pre-MED  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: pre-MED
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: don't use MAKE_PTR/OFFSET for shmem pointers
Next
From: Alvaro Herrera
Date:
Subject: Re: pre-MED