Re: [HACKERS] Keeping CURRENT_DATE and similar constructs in original format

[Tom Lane]

Peter Eisentraut  writes:
> 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.

Thanks for reviewing this patch.  I've pushed it now.

>> (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.

I went with SQLValueFunction.

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] Keeping CURRENT_DATE and similar constructs in original format

[Peter Eisentraut]

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


-- 
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] Keeping CURRENT_DATE and similar constructs in original format

[David G. Johnston]

On Thursday, May 12, 2016, Tom Lane  wrote:

> "David G. Johnston" > writes:
> > On Thursday, May 12, 2016, Tom Lane 
> > ');>>
> wrote:
> >> (I'm not particularly in love with the node type name
> >> ValueFunction; anybody got a better idea?)
>
> > SQL99DateTimeFunction (or roughly whenever they were introduced)?
>
> Some of them aren't datetime-related, though.  I thought about
> NiladicFunction but it seemed maybe too technical.
>
>
The time ones taking precision confuse things a bit but my first reaction
was positive.  It is readily grepable.  I'd rather have that over
ValueFunction.

David J.

Re: [HACKERS] Keeping CURRENT_DATE and similar constructs in original format

[Tom Lane]

"David G. Johnston"  writes:
> On Thursday, May 12, 2016, Tom Lane  > wrote:
>> (I'm not particularly in love with the node type name
>> ValueFunction; anybody got a better idea?)

> SQL99DateTimeFunction (or roughly whenever they were introduced)?

Some of them aren't datetime-related, though.  I thought about
NiladicFunction but it seemed maybe too technical.

> I agree with the premise.  I took notice of it recently in explain output
> on these lists using current_date.  That example read like
> ('now'::cstring)::date which was really odd since I was at least expecting
> text as the intermediate cast...

Yeah, that's another fun thing: the reverse listing currently differs
depending on whether you're looking at an expression tree that's been
through const-folding.  It didn't use to --- looks like the mention
of cstring started in 9.2.

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