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

From Tom Lane
Subject Re: dblink: add polymorphic functions.
Date
Msg-id 31530.1438225092@sss.pgh.pa.us
Whole thread Raw
In response to Re: dblink: add polymorphic functions.  (Joe Conway <mail@joeconway.com>)
Responses Re: dblink: add polymorphic functions.
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> On 07/29/2015 05:13 PM, Tom Lane wrote:
>> What's possibly more palatable is to introduce some other special
>> notation for "obtain the type of this expression at parse time".
>> I'm thinking for example about
>> 
>> SELECT x::pg_typeof(some_expression) FROM ...

> You think this could be made to work?

>     SELECT x::TYPE OF(some_expression) FROM ...

Hmmm ... that looks kind of nice, but a quick experiment with
bison says it's ambiguous.  I tried this just as proof-of-concept:

*** src/backend/parser/gram.y~    Fri Jul 24 21:40:02 2015
--- src/backend/parser/gram.y    Wed Jul 29 22:45:04 2015
*************** GenericType:
*** 11065,11070 ****
--- 11065,11074 ----                     $$->typmods = $3;                     $$->location = @1;                 }
+             | TYPE_P OF '(' a_expr ')'
+                 {
+                     $$ = makeTypeNameFromNameList(lcons(makeString($1), $2));
+                 }         ;  opt_type_modifiers: '(' expr_list ')'                { $$ = $2; }

and got a shift/reduce conflict.  I'm not quite sure why, but since OF
is also not a reserved keyword, it's likely that this is unfixable.
In fact, I also tried "TYPE_P FROM", not because that is especially
great syntax but because FROM *is* fully reserved, and that did not
work either.  So this isn't looking like a promising line of thought.

We can definitely do
SELECT x::any_single_unreserved_word(some_expression) FROM ...

because that's actually not something the grammar needs to distinguish
from type-with-a-typmod; we can deal with the special case in
LookupTypeName.  It's just a matter of picking a word people like.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: The real reason why TAP testing isn't ready for prime time
Next
From: Tom Lane
Date:
Subject: Re: The real reason why TAP testing isn't ready for prime time