Re: pre-MED

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pre-MED
Date: 2008-11-03 15:02:36
Message-ID: 26476.1225724556@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

  • Re: pre-MED at 2008-11-03 13:02:24 from Alvaro Herrera

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-11-03 15:02:37 Re: pre-MED
Previous Message Alvaro Herrera 2008-11-03 14:48:52 Re: don't use MAKE_PTR/OFFSET for shmem pointers