Re: Getting rid of SQLValueFunction - Mailing list pgsql-hackers

From Ian Lawrence Barwick
Subject Re: Getting rid of SQLValueFunction
Date
Msg-id CAB8KJ=jQEnn9sYG+N752spt68wMrhmT-ocHCh4oeNmHF82QMWA@mail.gmail.com
Whole thread Raw
In response to Re: Getting rid of SQLValueFunction  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Getting rid of SQLValueFunction  (Michael Paquier <michael@paquier.xyz>)
Re: Getting rid of SQLValueFunction  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi

2022年11月21日(月) 18:39 Michael Paquier <michael@paquier.xyz>:
>
> On Sun, Nov 20, 2022 at 03:15:34PM -0800, Ted Yu wrote:
> > + * timestamp.  These require a specific handling with their typmod is given
> > + * by the function caller through their SQL keyword.
> >
> > typo: typmod is given -> typmod given
> >
> > Other than the above, code looks good to me.
>
> Thanks for double-checking.  I intended a different wording, actually,
> so fixed this one.  And applied after an extra round of reviews.

I noticed this commit (f193883f) introduces following regressions:

    postgres=# SELECT current_timestamp(7);
    WARNING:  TIMESTAMP(7) WITH TIME ZONE precision reduced to maximum
allowed, 6
    ERROR:  timestamp(7) precision must be between 0 and 6

    postgres=# SELECT localtimestamp(7);
    WARNING:  TIMESTAMP(7) precision reduced to maximum allowed, 6
    ERROR:  timestamp(7) precision must be between 0 and 6

Suggested fix attached.

Regards

Ian Barwick

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
Next
From: Richard Guo
Date:
Subject: Re: Check lateral references within PHVs for memoize cache keys