Re: CAST vs ::

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thursday, July 13, 2017, Tom Lane <tgl@sss.pgh.pa.us> 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