From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | cary huang <hcary328(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add support for AT LOCAL |
Date: | 2023-10-03 00:10:48 |
Message-ID: | 91995214-7e91-64f8-2577-1465ed15fa35@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/29/23 09:27, Michael Paquier wrote:
> On Sat, Sep 23, 2023 at 12:54:01AM +0200, Vik Fearing wrote:
>> On 9/22/23 23:46, cary huang wrote:
>>> I think this feature can be a useful addition in dealing with time
>>> zones. I have applied and tried out the patch, The feature works as
>>> described and seems promising. The problem with compilation failure
>>> was probably reported on CirrusCI when compiled on different
>>> platforms. I have run the latest patch on my own Cirrus CI environment
>>> and everything checked out fine.
>>
>> Thank you for reviewing!
>
> + | a_expr AT LOCAL %prec AT
> + {
> + /* Use the value of the session's time zone */
> + FuncCall *tz = makeFuncCall(SystemFuncName("current_setting"),
> + list_make1(makeStringConst("TimeZone", -1)),
> + COERCE_SQL_SYNTAX,
> + -1);
> + $$ = (Node *) makeFuncCall(SystemFuncName("timezone"),
> + list_make2(tz, $1),
> + COERCE_SQL_SYNTAX,
> + @2);
>
> As the deparsing code introduced by this patch is showing, this leads
> to a lot of extra complexity. And, actually, this can be quite
> expensive as well with these two layers of functions. Note also that
> in comparison to SQLValueFunctions, COERCE_SQL_SYNTAX does less
> inlining. So here comes my question: why doesn't this stuff just use
> one underlying function to do this job?
I guess I don't understand the question. Why do you think a single
function that repeats what these functions do would be preferable? I am
not sure how doing it a different way would be better.
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2023-10-03 00:21:21 | Re: Allow deleting enumerated values from an existing enumerated data type |
Previous Message | Tom Lane | 2023-10-03 00:08:37 | Re: CHECK Constraint Deferrable |