Re: [HACKERS] CAST vs ::

[Tom Lane]

"David G. Johnston"  writes:
> On Thursday, July 13, 2017, Tom Lane  wrote:
>> Maybe we can hack ruleutils to use
>> the CAST syntax only in this specific context.

> Given the lack of complaints, and ubiquity of ::, this would seem ideal
> and sufficient. While there is something to be said for using standard
> compliant syntax changing just this like doesn't seem like it would move
> the goalposts meaningfully.

Hm, it's worse than I thought: the argument of the CAST expression
needn't be a function call at all, and on top of that, the parser
will throw away a no-op cast altogether.  So for example:

regression=# create view vvc as select * from cast(1+2 as int) c(x);
CREATE VIEW
regression=# \d+ vvc
 View "public.vvc"
 Column |  Type   | Collation | Nullable | Default | Storage | Description 
+-+---+--+-+-+-
 x  | integer |   |  | | plain   | 
View definition:
 SELECT c.x
   FROM 1 + 2 c(x);

To make the world safe for this behavior by extending the grammar,
we'd have to be prepared to accept an arbitrary a_expr, without even
surrounding parentheses, as a FROM item.  I don't think there's much
chance of making that work without grammar conflicts, and even if we
managed, the SQL committee would probably find a way to break it with
some future feature addition.

So what I'm now thinking is to make ruleutils.c look at the expression in
an RTE_FUNCTION FROM item and see if it will decompile as something with
the syntax of a function call.  If not, or if there's any doubt, emit a
dummy CAST(... AS sametype) around it.  That would cause the above example
to come out the way it went in.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CAST vs ::

[David G. Johnston]

On Thursday, July 13, 2017, Tom Lane  wrote:

> Maybe we can hack ruleutils to use
> the CAST syntax only in this specific context.
>

Given the lack of complaints, and ubiquity of ::, this would seem ideal
and sufficient. While there is something to be said for using standard
compliant syntax changing just this like doesn't seem like it would move
the goalposts meaningfully.

David J.