Em ter., 24 de jan. de 2023 às 07:24, Dean Rasheed
escreveu:
> On Tue, 24 Jan 2023 at 00:47, Ranier Vilela wrote:
> >
> > On 13.01.23 11:01, Dean Rasheed wrote:
> > > So I'm feeling quite good about the end result -- I set out hoping not
> > > to make performance noticeably worse, but ended up
On Tue, 24 Jan 2023 at 00:47, Ranier Vilela wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
> Hi Dean, thanks for your work.
>
>
On 13.01.23 11:01, Dean Rasheed wrote:
> So I'm feeling quite good about the end result -- I set out hoping not
> to make performance noticeably worse, but ended up making it
> significantly better.
Hi Dean, thanks for your work.
But since PG_RETURN_NULL, is a simple return,
now the "value" var
On Mon, 23 Jan 2023 at 20:00, Joel Jacobson wrote:
>
> Nice! This also simplifies when dealing with non-negative integers
> represented as byte arrays,
> common in e.g. cryptography code.
>
Ah, interesting. I hadn't thought of that use-case.
> create function numeric_from_bytes(bytea) returns
On Fri, Jan 13, 2023, at 07:01, Dean Rasheed wrote:
> Attachments:
> * 0001-Add-non-decimal-integer-support-to-type-numeric.patch
Nice! This also simplifies when dealing with non-negative integers represented
as byte arrays,
common in e.g. cryptography code.
Before, one had to implement
On Mon, 23 Jan 2023 at 15:55, Peter Eisentraut
wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
>
> This is great! How do you
On 13.01.23 11:01, Dean Rasheed wrote:
So I'm feeling quite good about the end result -- I set out hoping not
to make performance noticeably worse, but ended up making it
significantly better.
This is great! How do you want to proceed? You also posted an updated
patch in the "underscores"
On Wed, 14 Dec 2022 at 05:47, Peter Eisentraut
wrote:
>
> committed
Now that we have this for integer types, I think it's worth doing for
numeric as well, since the parser will now pass such things through to
numeric_in() when they don't fit in an int64, and it seems plausible
that at least some
On 08.12.22 12:16, Peter Eisentraut wrote:
On 29.11.22 21:22, David Rowley wrote:
There seems to be a small bug in the pg_strtointXX functions in the
code that checks that there's at least 1 digit. This causes 0x to be
a valid representation of zero. That does not seem to be allowed by
the
rom: Peter Eisentraut
Date: Thu, 8 Dec 2022 12:10:41 +0100
Subject: [PATCH v12] Non-decimal integer literals
Add support for hexadecimal, octal, and binary integer literals:
0x42F
0o273
0b100101
per SQL:202x draft.
This adds support in the lexer as well as in the integer type input
David Rowley writes:
> I agree that it should be a separate patch. But thinking about what
> Tom mentioned in [1], I had in mind this patch would need to wait
> until the new standard is out so that we have a more genuine reason
> for breaking existing queries.
Well, we already broke them in
On Thu, 1 Dec 2022 at 00:34, Dean Rasheed wrote:
> So something
> like:
>
> // Accumulate positive value using unsigned int, with approximate
> // overflow check. If acc >= 1 - INT_MIN / 10, then acc * 10 is
> // sure to exceed -INT_MIN.
> unsigned int cutoff = 1 - INT_MIN / 10;
>
On Wed, 30 Nov 2022 at 05:50, David Rowley wrote:
>
> I spent a bit more time trying to figure out why the compiler does
> imul instead of bit shifting and it just seems to be down to a
> combination of signed-ness plus the overflow check. See [1]. Neither
> of the two compilers I tested could
On Wed, 23 Nov 2022 at 22:19, John Naylor wrote:
>
>
> On Wed, Nov 23, 2022 at 3:54 PM David Rowley wrote:
> >
> > Going by [1], clang will actually use multiplication by 16 to
> > implement the former. gcc is better and shifts left by 4, so likely
> > won't improve things for gcc. It seems
On Tue, 29 Nov 2022 at 03:00, Peter Eisentraut
wrote:
> Fixed in new patch.
There seems to be a small bug in the pg_strtointXX functions in the
code that checks that there's at least 1 digit. This causes 0x to be
a valid representation of zero. That does not seem to be allowed by
the parser,
On Tue, 29 Nov 2022 at 23:11, Dean Rasheed wrote:
>
> On Wed, 23 Nov 2022 at 08:56, David Rowley wrote:
> >
> > On Wed, 23 Nov 2022 at 21:54, David Rowley wrote:
> > > I wonder if you'd be better off with something like:
> > >
> > > while (*ptr && isxdigit((unsigned char) *ptr))
> > >
On Wed, 23 Nov 2022 at 08:56, David Rowley wrote:
>
> On Wed, 23 Nov 2022 at 21:54, David Rowley wrote:
> > I wonder if you'd be better off with something like:
> >
> > while (*ptr && isxdigit((unsigned char) *ptr))
> > {
> > if (unlikely(tmp &
On Sat, 26 Nov 2022 at 05:13, Peter Eisentraut
wrote:
>
> On 24.11.22 10:13, David Rowley wrote:
> > I
> > remember many years ago and several jobs ago when working with SQL
> > Server being able to speed up importing data using hexadecimal
> > DATETIMEs. I can't think why else you might want to
through to numeric_in() and fail:
Fixed in new patch.
From 2d7f41981187df904e3d985f2770d9b5c26e9d7c Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 28 Nov 2022 09:24:20 +0100
Subject: [PATCH v11] Non-decimal integer literals
Add support for hexadecimal, octal, and binary integer literals
On 24.11.22 10:13, David Rowley wrote:
On Thu, 24 Nov 2022 at 21:35, Peter Eisentraut
wrote:
My code follows the style used for parsing the decimal integers.
Keeping that consistent is valuable I think. I think the proposed
change makes the code significantly harder to understand. Also, what
On Thu, 24 Nov 2022 at 21:35, Peter Eisentraut
wrote:
> My code follows the style used for parsing the decimal integers.
> Keeping that consistent is valuable I think. I think the proposed
> change makes the code significantly harder to understand. Also, what
> you are suggesting here would
On 23.11.22 09:54, David Rowley wrote:
On Wed, 23 Nov 2022 at 02:37, Peter Eisentraut
wrote:
Here is a new patch.
This looks like quite an inefficient way to convert a hex string into an int64:
while (*ptr && isxdigit((unsigned char) *ptr))
{
int8digit
On Tue, 22 Nov 2022 at 13:37, Peter Eisentraut
wrote:
>
> On 15.11.22 11:31, Peter Eisentraut wrote:
> > On 14.11.22 08:25, John Naylor wrote:
> >> Regarding the patch, it looks good overall. My only suggestion would
> >> be to add a regression test for just below and just above overflow, at
> >>
On Wed, Nov 23, 2022 at 3:54 PM David Rowley wrote:
>
> Going by [1], clang will actually use multiplication by 16 to
> implement the former. gcc is better and shifts left by 4, so likely
> won't improve things for gcc. It seems worth doing it this way for
> anything that does not have
On Wed, 23 Nov 2022 at 21:54, David Rowley wrote:
> I wonder if you'd be better off with something like:
>
> while (*ptr && isxdigit((unsigned char) *ptr))
> {
> if (unlikely(tmp & UINT64CONST(0xF000)))
> goto out_of_range;
>
>
On Wed, 23 Nov 2022 at 02:37, Peter Eisentraut
wrote:
> Here is a new patch.
This looks like quite an inefficient way to convert a hex string into an int64:
while (*ptr && isxdigit((unsigned char) *ptr))
{
int8digit = hexlookup[(unsigned char) *ptr];
On Tue, Nov 22, 2022 at 8:36 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 15.11.22 11:31, Peter Eisentraut wrote:
> > On 14.11.22 08:25, John Naylor wrote:
> >> Regarding the patch, it looks good overall. My only suggestion would
> >> be to add a regression test for just
7 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 22 Nov 2022 14:22:09 +0100
Subject: [PATCH v10] Non-decimal integer literals
Add support for hexadecimal, octal, and binary integer literals:
0x42F
0o273
0b100101
per SQL:202x draft.
This adds support in the lexer as well as in the in
to
rephrase.
ok
+T661 Non-decimal integer literals YES SQL:202x draft
Is there an ETA yet?
March 2023
Also, it's not this patch's job to do it, but there are at least a half
dozen places that open-code turning a hex char into a number. It might
be a good easy "todo item" to unify that.
right
thing with
{numeric},
I scratched my head for a while, thinking this was Flex syntax, until I
realized my brain was supposed to do shell-globbing first, at which point I
could see it was referring to multiple Flex rules. I'd try to rephrase.
+T661 Non-decimal integer literals YES SQL:202x draft
I
On Tue, Oct 11, 2022 at 4:59 PM Peter Eisentraut
wrote:
>
> On 11.10.22 05:29, Junwang Zhao wrote:
> > What do you think if we move these code into a static inline function? like:
> >
> > static inline char*
> > process_digits(char *ptr, int32 *result)
> > {
> > ...
> > }
>
> How would you handle
On 11.10.22 05:29, Junwang Zhao wrote:
What do you think if we move these code into a static inline function? like:
static inline char*
process_digits(char *ptr, int32 *result)
{
...
}
How would you handle the different ways each branch checks for valid
digits and computes the value of each
t; The remaining patches are material for PG16 at this point, and I will
> > set the commit fest item to returned with feedback in the meantime.
>
> Time to continue with this.
>
> Attached is a rebased and cleaned up patch for non-decimal integer
> literals. (I don'
On 16.02.22 11:11, Peter Eisentraut wrote:
The remaining patches are material for PG16 at this point, and I will
set the commit fest item to returned with feedback in the meantime.
Time to continue with this.
Attached is a rebased and cleaned up patch for non-decimal integer
literals. (I
On 13.02.22 13:14, John Naylor wrote:
On Wed, Jan 26, 2022 at 10:10 PM Peter Eisentraut
wrote:
[v8 patch]
0001-0004 seem pretty straightforward.
These have been committed.
0005:
{realfail1} {
- /*
- * throw back the [Ee], and figure out whether what
- * remains is an {integer} or
Re: Peter Eisentraut
> This adds support in the lexer as well as in the integer type input
> functions.
>
> Those core parts are straightforward enough, but there are a bunch of other
> places where integers are parsed, and one could consider in each case
> whether they should get the same
On Wed, Jan 26, 2022 at 10:10 PM Peter Eisentraut
wrote:
> [v8 patch]
0001-0004 seem pretty straightforward.
0005:
{realfail1} {
- /*
- * throw back the [Ee], and figure out whether what
- * remains is an {integer} or {decimal}.
- */
- yyless(yyleng - 1);
SET_YYLLOC();
- return
On 1/25/22 13:43, Alvaro Herrera wrote:
> On 2022-Jan-24, Peter Eisentraut wrote:
>
>> +decinteger {decdigit}(_?{decdigit})*
>> +hexinteger 0[xX](_?{hexdigit})+
>> +octinteger 0[oO](_?{octdigit})+
>> +bininteger 0[bB](_?{bindigit})+
> I think there should be
On 26.01.22 01:02, Tom Lane wrote:
Robert Haas writes:
On Tue, Jan 25, 2022 at 5:34 AM Peter Eisentraut
wrote:
Which part exactly? There are several different changes proposed here.
I was just going based on the description of the feature in your
original post. If someone is hoping that
Robert Haas writes:
> On Tue, Jan 25, 2022 at 5:34 AM Peter Eisentraut
> wrote:
>> Which part exactly? There are several different changes proposed here.
> I was just going based on the description of the feature in your
> original post. If someone is hoping that int4in() will accept only
>
On 2022-Jan-24, Peter Eisentraut wrote:
> +decinteger {decdigit}(_?{decdigit})*
> +hexinteger 0[xX](_?{hexdigit})+
> +octinteger 0[oO](_?{octdigit})+
> +bininteger 0[bB](_?{bindigit})+
I think there should be test cases for literals that these seemingly
On Tue, Jan 25, 2022 at 5:34 AM Peter Eisentraut
wrote:
> On 24.01.22 19:53, Robert Haas wrote:
> > On Mon, Jan 24, 2022 at 3:41 AM Peter Eisentraut
> > wrote:
> >> Rebased patch set
> >
> > What if someone finds this new behavior too permissive?
>
> Which part exactly? There are several
On 24.01.22 19:53, Robert Haas wrote:
On Mon, Jan 24, 2022 at 3:41 AM Peter Eisentraut
wrote:
Rebased patch set
What if someone finds this new behavior too permissive?
Which part exactly? There are several different changes proposed here.
On Mon, Jan 24, 2022 at 3:41 AM Peter Eisentraut
wrote:
> Rebased patch set
What if someone finds this new behavior too permissive?
--
Robert Haas
EDB: http://www.enterprisedb.com
1: SELECT .0a;
+ ^
SELECT 0.0e1a;
- a
- 0
-(1 row)
-
+ERROR: trailing junk after numeric literal at or near "0.0e1a"
+LINE 1: SELECT 0.0e1a;
+ ^
SELECT 0.0e;
- e
------
- 0.0
-(1 row)
-
+ERROR: trailing junk after numeric literal at or near "0
ear "0.0e1a"
+LINE 1: SELECT 0.0e1a;
+ ^
SELECT 0.0e;
- e
--
- 0.0
-(1 row)
-
+ERROR: trailing junk after numeric literal at or near "0.0e"
+LINE 1: SELECT 0.0e;
+ ^
SELECT 0.0e+a;
-ERROR: syntax error at or near "+"
+ERROR: trai
^
SELECT 0.0a;
- a
--
- 0.0
-(1 row)
-
+ERROR: trailing junk after numeric literal at or near "0.0a"
+LINE 1: SELECT 0.0a;
+ ^
SELECT .0a;
- a
--
- 0.0
-(1 row)
-
+ERROR: trailing junk after numeric literal at or near ".0a"
+LINE 1:
On 25.11.21 18:51, John Naylor wrote:
If we're going to change the comment anyway, "the parser" sounds more
natural. Aside from that, 0001 and 0002 can probably be pushed now, if
you like.
done
--- a/src/interfaces/ecpg/preproc/pgc.l
+++ b/src/interfaces/ecpg/preproc/pgc.l
@@ -365,6 +365,10
On 25.11.21 16:46, Zhihong Yu wrote:
For patch 3,
+int64
+pg_strtoint64(const char *s)
How about naming the above function pg_scanint64()?
pg_strtoint64xx() can be named pg_strtoint64() - this would align with
existing function:
pg_strtouint64(const char *str, char **endptr, int base)
Hi Peter,
0001
-/* we no longer allow unary minus in numbers.
- * instead we pass it separately to parser. there it gets
- * coerced via doNegate() -- Leon aug 20 1999
+/*
+ * Numbers
+ *
+ * Unary minus is not part of a number here. Instead we pass it
separately to
+ * parser, and there it
railing junk after
> numeric literals, as discussed. I have expanded that compared to the v4
> patch to also cover non-integer literals. It also comes with more tests
> now. Patch 6 is the titular introduction of non-decimal integer
> literals, unchanged from before.
Hi,
For patch 3,
+
is the titular introduction of non-decimal integer
literals, unchanged from before.From 39aed9c0516fcf0a6b3372361ecfcf4874614578 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 24 Nov 2021 09:10:32 +0100
Subject: [PATCH v5 1/6] Improve some comments in scanner files
---
src/backend/parser
6e081c44c04201ee9ded9dc6b689824ccabdfc28 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sun, 31 Oct 2021 15:42:18 +0100
Subject: [PATCH v4] Non-decimal integer literals
Add support for hexadecimal, octal, and binary integer literals:
0x42F
0o273
0b100101
per SQL:202x draft.
This adds support
On 09.09.21 16:08, Vik Fearing wrote:
Even without that point, this patch *is* going to break valid queries,
because every one of those cases is a valid number-followed-by-identifier
today,
Ah, true that. So if this does go in, we may as well add the
underscores at the same time.
Yeah,
e.
Good point, here is a lightly updated patch.
From 43957a1f48ed6f750f231ef8e3533d74d7ac4cc9 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 28 Sep 2021 17:14:44 +0200
Subject: [PATCH v3] Non-decimal integer literals
Add support for hexadecimal, octal, and binary integer literals:
On 9/8/21 3:14 PM, Tom Lane wrote:
> Vik Fearing writes:
>
>> Is there any hope of adding the optional underscores? I see a potential
>> problem there as SELECT 1_a; is currently parsed as SELECT 1 AS _a; when
>> it should be parsed as SELECT 1_ AS a; or perhaps even as an error since
>> 0x1_a
Vik Fearing writes:
> On 8/16/21 11:51 AM, Peter Eisentraut wrote:
>> Here is a patch to add support for hexadecimal, octal, and binary
>> integer literals:
>>
>> 0x42E
>> 0o112
>> 0b100101
>>
>> per SQL:202x draft.
> Is there any hope of adding the optional underscores? I see a
On 8/16/21 11:51 AM, Peter Eisentraut wrote:
> Here is a patch to add support for hexadecimal, octal, and binary
> integer literals:
>
> 0x42E
> 0o112
> 0b100101
>
> per SQL:202x draft.
Is there any hope of adding the optional underscores? I see a potential
problem there as SELECT
On Tue, Sep 7, 2021 at 4:13 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 16.08.21 17:32, John Naylor wrote:
> > The one thing that jumped out at me on a cursory reading is
> > the {integer} rule, which seems to be used nowhere except to
> > call process_integer_literal,
separate
process_*_literal functions?
Agreed, that can be done in a simpler way. Here is an updated patch.
From f90826f77d8067a1641f60dd75d5ea1d83466ea9 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 7 Sep 2021 13:10:18 +0200
Subject: [PATCH v2] Non-decimal integer literals
Add support
On Mon, Aug 16, 2021 at 5:52 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> Here is a patch to add support for hexadecimal, octal, and binary
> integer literals:
>
> 0x42E
> 0o112
> 0b100101
>
> per SQL:202x draft.
>
> This adds support in the lexer as well as
09:32:14 +0200
Subject: [PATCH v1] Non-decimal integer literals
Add support for hexadecimal, octal, and binary integer literals:
0x42E
0o112
0b100101
per SQL:202x draft.
This adds support in the lexer as well as in the integer type input
functions.
---
doc/src/sgml/syntax.sgml
62 matches
Mail list logo
