Re: dblink: add polymorphic functions. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: dblink: add polymorphic functions.
Date
Msg-id 24240.1452267070@sss.pgh.pa.us
Whole thread Raw
In response to Re: dblink: add polymorphic functions.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: dblink: add polymorphic functions.  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Joe Conway wrote:
>> On 07/30/2015 09:51 AM, Tom Lane wrote:
>>> The main limitation of this patch is that it won't work for call sites
>>> that pass pstate == NULL to LookupTypeName.  There are a fair number
>>> of them, some of which wouldn't care because they could never invoke
>>> this notation anyway, but for others we'd need to do some work to cons
>>> up a suitable pstate.

>> Sorry it took so long for me to get back to this, but any reason the
>> attached won't work?

> So, is this going anywhere?

Oh, sorry, was I on the hook to review that?

[ quick look... ]  This doesn't seem like it responds to my criticism
above.  I think what we want is that for every LookupTypeName call site
that could potentially be invoking this notation, we must actually make
provision for passing a valid pstate, one containing in particular the
source text for the nodetree we're parsing.  Without that we will not
get error messages of the quality we expect (with error pointers).

Another issue now that I look at it is that parser-detected semantic
problems in the expression will result in ereport(ERROR), rather than
returning NULL which is what you'd kind of expect from the API spec for
LookupTypeName.  That's probably all right considering that many other
syntactic issues throw errors inside this function; but maybe we'd better
adjust the API spec.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Blind attempt at a Cygwin fix
Next
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Blind attempt at a Cygwin fix