On 5/12/16 6:14 PM, Tom Lane wrote:
> So what I've wanted to do for some time is invent a new expression node
> type that represents any one of these functions and can be reverse-listed
> in the same format that the input had. The attached proposed patch does
> that.
I was experimenting with this as well when I found your patch, and I
think this is the right solution. Your patch works fine for me.
Because of the refactoring in 2f153ddfdd318b211590dd5585f65f357d85c2de,
you will need to update your patch a bit.
> (I'm not particularly in love with the node type name
> ValueFunction; anybody got a better idea?)
I think this is fine. The only other idea I have would be
SQLValueFunction, to emphasize that this is about SQL-mandated special
cases.
> By the by, a scan through gram.y reveals other stuff we aren't trying
> to reverse-list in original form:
>
> a_expr AT TIME ZONE a_expr
> LIKE, ILIKE, SIMILAR TO
> OVERLAPS
> BETWEEN
> COLLATION FOR '(' a_expr ')'
> EXTRACT '(' extract_list ')'
> OVERLAY '(' overlay_list ')'
> POSITION '(' position_list ')'
> SUBSTRING '(' substr_list ')'
> TREAT '(' a_expr AS Typename ')'
> TRIM '(' BOTH trim_list ')'
> TRIM '(' LEADING trim_list ')'
> TRIM '(' TRAILING trim_list ')'
> TRIM '(' trim_list ')'
>
> Each of these gets converted to some PG-specific function or operator
> name, and then will get reverse-listed using that name and ordinary
> function or operator syntax, rather than using the SQL-approved special
> syntax.
I think those could be addressed by having ruleutils.c *always* convert
matching function calls back to the special syntax. Alternatively, tag
the function call node in the grammar with "this is special syntax" and
then look for that in ruleutils.c. This is sort of what I was playing
with, except that the several levels of casting for the datetime
functions make that a mess. If it's only one function call, it should
be easier.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
