"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Thursday, July 13, 2017, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
