From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Gunnar \"Nick\" Bluth" <gunnar(dot)bluth(at)pro-open(dot)de> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SELECT of pseudo hex value gives unexpected result |
Date: | 2019-01-29 16:39:29 |
Message-ID: | 7563.1548779969@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Gunnar \"Nick\" Bluth" <gunnar(dot)bluth(at)pro-open(dot)de> writes:
> Tried
> SELECT 0x5e73266725;
> and received:
> -[ RECORD 1 ]--
> x5e73266725 | 0
> That was not what I expected... is this expected/documented behaviour?
Well, there are no hex literals in (PG's notion of) SQL, so that isn't
a valid token. But it's the concatenation of two valid tokens. So
what you wrote is the same as
SELECT 0 x5e73266725;
which is an abbreviation for
SELECT 0 AS x5e73266725;
and that's the result you got.
I think that the SQL standard considers adjacent tokens to be invalid
unless one of them is punctuation (e.g. 1+2), but our lexer is a bit
less rigid about that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2019-01-29 16:41:21 | Re: SELECT of pseudo hex value gives unexpected result |
Previous Message | Gunnar "Nick" Bluth | 2019-01-29 16:18:07 | SELECT of pseudo hex value gives unexpected result |