On Sun, Jun 06, 2021 at 03:10:07PM -0400, Tom Lane wrote:
> I wrote:
> > We could make use of COMPARE_COERCIONFORM_FIELD 100% correct by removing
> > these two tests of the funcformat value, but on the whole I doubt that
> > would be better.
>
> On still closer inspection, that seems like it'd be
I wrote:
> We could make use of COMPARE_COERCIONFORM_FIELD 100% correct by removing
> these two tests of the funcformat value, but on the whole I doubt that
> would be better.
On still closer inspection, that seems like it'd be fine. All of
the gram.y productions that emit COERCE_SQL_SYNTAX also
I wrote:
> Noah Misch writes:
>> equalfuncs.c has been using COMPARE_COERCIONFORM_FIELD() to ignore
>> differences
>> in fields of this type. Does this spot have cause to depart from the
>> pattern?
> Oversight, I think. Will fix.
After looking closer, I see that there are a couple of very
Noah Misch writes:
> equalfuncs.c has been using COMPARE_COERCIONFORM_FIELD() to ignore differences
> in fields of this type. Does this spot have cause to depart from the pattern?
Oversight, I think. Will fix.
regards, tom lane
On Tue, Nov 03, 2020 at 07:22:14PM -0500, Tom Lane wrote:
> I feel like this is committable at this point --- any objections?
(This became commit 40c24bf, "Improve our ability to regurgitate SQL-syntax
function calls.")
> --- a/src/backend/nodes/equalfuncs.c
> +++
Thomas Munro writes:
> On Wed, Apr 28, 2021 at 3:56 AM Tom Lane wrote:
>> Of course Wikipedia has been known to contain errors, but now
>> I'm inclined to think I blew this. Anyone want to check my work?
> I tried a couple of examples not from Wikipedia. ...
Thanks for checking! I'll go
On Wed, Apr 28, 2021 at 3:56 AM Tom Lane wrote:
> Of course Wikipedia has been known to contain errors, but now
> I'm inclined to think I blew this. Anyone want to check my work?
I tried a couple of examples not from Wikipedia. First, from the
definition of Julian days as used by
I wrote:
>> Perhaps it'd be worth documenting that you can get the standard
>> astronomical definition of Julian date by transposing to time zone UTC-12
>> before converting.
BTW ... I'd first thought that the way to do this was to rotate to
time zone UTC+12. I convinced myself on two separate
I wrote:
> So I don't think there's any code change required (unless you are still
> worried about speed). What we do need is documentation fixes:
> * clarify the above bit about local vs UTC midnight
> * document the existence of the julian field for date_part/extract
> * fix this bit in the
Peter Eisentraut writes:
> The extract(julian from timestamp) is still a bit in the slow mode, but
> as I previously stated, it's not documented and gives the wrong result,
> so it's not clear whether it should be fixed and what it should do. I
> think I'll register that part as an open item
On 01.04.21 20:49, Peter Eisentraut wrote:
also done
I also figured out a way to combine the float8 and numeric
implementations so that there is not so much duplication. Added tests
to cover all the edge and overflow cases.
I think this is solid now.
The extract(julian from timestamp) is
On 19.03.21 21:06, Tom Lane wrote:
Yeah, I was wondering if we could do something like that, but I hadn't
got as far as figuring a way to deal with divisors not a multiple of
NBASE.
Looking at the proposed code, I wonder if it wouldn't be better to
define the function as taking the base-10-log
Peter Eisentraut writes:
> On 19.03.21 21:06, Tom Lane wrote:
>> I guess the immediate question is how much of a performance gap there
>> is now between the float and numeric implementations.
> Attached are my test script and the full output.
OK ... I prefer to do this sort of timing in a way
On 19.03.21 21:06, Tom Lane wrote:
I guess the immediate question is how much of a performance gap there
is now between the float and numeric implementations.
Attached are my test script and the full output.
To summarize, for cases that don't do any interesting computation and
where the
Peter Eisentraut writes:
> Well, I had an idea that I put to work. In most of these cases where we
> need division, we divide an integer by a power of 10. That can be done
> with numeric very quickly by just shifting the weight and scale around.
> So I wrote a function that does that
On 18.03.21 09:28, Peter Eisentraut wrote:
Which leads me to: After retesting this now, with a new machine, the
performance of the numeric implementation is brutal compared to the
float implementation, for cases where we need numeric division, which is
milliseconds, seconds, and epoch. In
On 15.03.21 18:35, Tom Lane wrote:
Anyway, taking a quick look at the v4 patch, the only complaint
I have is that it seems a bit bulky and brute-force to duplicate
so much code. Is it feasible to share most of the implementation
between old and new functions, returning (say) an int64 that can
David Steele writes:
> On 12/15/20 9:03 AM, Peter Eisentraut wrote:
>> Here is a new patch for this. This now follows the implementation that
>> Tom has suggested: Leave date_part() alone, add a new set of extract()
>> functions, and map the SQL EXTRACT construct to those. I have basically
On 12/15/20 9:03 AM, Peter Eisentraut wrote:
Here is a new patch for this. This now follows the implementation that
Tom has suggested: Leave date_part() alone, add a new set of extract()
functions, and map the SQL EXTRACT construct to those. I have basically
just copied over the
Here is a new patch for this. This now follows the implementation that
Tom has suggested: Leave date_part() alone, add a new set of extract()
functions, and map the SQL EXTRACT construct to those. I have basically
just copied over the implementations from my previous patch and placed
them
I wrote:
> * I notice that this will sometimes transform non-SQL-spec syntax
> into SQL-spec, for example ...
> I'm not sure that that satisfies the POLA. This particular case is
> especially not great, because this is really textregexsubstr() which
> is *not* SQL compatible, so the display is
I wrote:
> Attached is a draft patch that does this. I'm fairly pleased with it,
> but there are some loose ends as described below. As the patch stands,
> it reverse-lists all our special-format function call syntaxes
> *except* EXTRACT. I left that out since I think we want to apply the
>
I wrote:
> However: suppose that we continue to translate these things into FuncExpr
> nodes, the same as always, but we add a new CoercionForm variant, say
> COERCE_SQL_SYNTAX. 99% of the system ignores FuncExpr.funcformat,
> and would continue to do so, but ruleutils.c would take it to mean
>
On Thu, Sep 17, 2020 at 02:53:27PM +0900, Michael Paquier wrote:
> As far as I can see, patches 0001 and 0002 have been already applied,
> but not 0003. Could you send a rebase to allow the CF bot to run, at
> least?
This was two weeks ago. Looking at 0003, the thing is not really
complicated,
On Wed, Sep 09, 2020 at 08:47:36PM +0200, Peter Eisentraut wrote:
> ok done
As far as I can see, patches 0001 and 0002 have been already applied,
but not 0003. Could you send a rebase to allow the CF bot to run, at
least?
--
Michael
signature.asc
Description: PGP signature
Em seg., 14 de set. de 2020 às 15:33, Tom Lane escreveu:
> Ranier Vilela writes:
> > msvc 2019 (64 bits), is worried about it:
> > C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334:
> > '<<': resultado de 32-bit shift convertido implicitamente para 64 bits
> > (64-bit
Ranier Vilela writes:
> msvc 2019 (64 bits), is worried about it:
> C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334:
> '<<': resultado de 32-bit shift convertido implicitamente para 64 bits
> (64-bit shift era pretendid
> o?) [C:\dll\postgres\postgres.vcxproj]
Yeah,
Peter Eisentraut writes:
> ok done
msvc 2019 (64 bits), is worried about it:
https://github.com/postgres/postgres/commit/0aa8f764088ea0f36620ae2955fa6c54ec736c46
"C:\dll\postgres\pgsql.sln" (default target) (1) ->
"C:\dll\postgres\cyrillic_and_mic.vcxproj" (default target) (37) ->
On 2020-09-09 15:38, Tom Lane wrote:
and a few
more calls of int8_numeric that could be converted. I think the
attached updated version is committable, and I'd recommend going
ahead with that regardless of the rest of this. I hadn't realized
how many random calls of int8_numeric and
Peter Eisentraut writes:
> On 2020-09-07 01:46, Tom Lane wrote:
>> I reviewed the 0002 patch, finding one bug (in int8_sum)
> Ouch, no test coverage. Should we perhaps remove this function, since
> it's obsolete and unused?
I don't feel a need to.
>> and a few
>> more calls of int8_numeric
On 2020-09-07 01:46, Tom Lane wrote:
Peter Eisentraut writes:
Here is a new patch series version.
I have created a new internal function for converting integers to
numeric, to make the implementation a bit more elegant and compact.
I reviewed the 0002 patch, finding one bug (in int8_sum)
po 7. 9. 2020 v 1:46 odesílatel Tom Lane napsal:
> Peter Eisentraut writes:
> > Here is a new patch series version.
> > I have created a new internal function for converting integers to
> > numeric, to make the implementation a bit more elegant and compact.
>
> I reviewed the 0002 patch,
Peter Eisentraut writes:
> Here is a new patch series version.
> I have created a new internal function for converting integers to
> numeric, to make the implementation a bit more elegant and compact.
I reviewed the 0002 patch, finding one bug (in int8_sum) and a few
more calls of int8_numeric
út 4. 8. 2020 v 16:08 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2020-05-25 15:28, Peter Eisentraut wrote:
> > On 2019-12-02 23:52, Thomas Munro wrote:
> >>> I'm not an expert in floating point math but hopefully it means that no
> >>> type change is required -
On 2020-05-25 15:28, Peter Eisentraut wrote:
On 2019-12-02 23:52, Thomas Munro wrote:
I'm not an expert in floating point math but hopefully it means that no
type change is required - double precision can handle it.
Me neither, but the SQL standard requires us to use an exact numeric
type, so
On Mon, May 25, 2020 at 09:43:32AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > One problem (other than perhaps performance, tbd.) is that this would no
> > longer allow processing infinite timestamps, since numeric does not
> > support infinity. It could be argued that running
I wrote:
> What had been a 100% spec-compliant view definition is now quite
> Postgres-specific. I fixed some similar problems in 0bb51aa96 (before
> that, the CURRENT_TIMESTAMP part would've reverse-listed differently
> too); but I didn't tackle EXTRACT(), SUBSTRING(), and other cases.
> I'm not
Vik Fearing writes:
> On 5/25/20 6:40 PM, Tom Lane wrote:
>> While at it, maybe we could
>> fix things so that the syntax reverse-lists the same way instead
>> of injecting Postgres-isms...
> I'm not sure what this means.
This:
regression=# create view myview as select extract(year from
On 5/25/20 6:40 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 5/25/20 3:28 PM, Peter Eisentraut wrote:
>>> I looked into this (changing the return types of date_part()/extract()
>>> from float8 to numeric).
>
>> I think what would be better is to have a specific date_part function
>> for each
Vik Fearing writes:
> On 5/25/20 3:28 PM, Peter Eisentraut wrote:
>> I looked into this (changing the return types of date_part()/extract()
>> from float8 to numeric).
> I think what would be better is to have a specific date_part function
> for each part and have extract translate to the
On 5/25/20 3:28 PM, Peter Eisentraut wrote:
> On 2019-12-02 23:52, Thomas Munro wrote:
>>> I'm not an expert in floating point math but hopefully it means that no
>>> type change is required - double precision can handle it.
>> Me neither, but the SQL standard requires us to use an exact numeric
Peter Eisentraut writes:
> One problem (other than perhaps performance, tbd.) is that this would no
> longer allow processing infinite timestamps, since numeric does not
> support infinity. It could be argued that running extract() on infinite
> timestamps isn't very useful, but it's
On 2019-12-02 23:52, Thomas Munro wrote:
I'm not an expert in floating point math but hopefully it means that no
type change is required - double precision can handle it.
Me neither, but the SQL standard requires us to use an exact numeric
type, so it's wrong on that level by definition.
I
43 matches
Mail list logo
