Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for? - Mailing list pgsql-general

From Tom Lane
Subject Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
Date
Msg-id 7621.1432313080@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?  (Bill Moran <wmoran@potentialtech.com>)
Responses Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?  (Bill Moran <wmoran@potentialtech.com>)
Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?  (PT <wmoran@potentialtech.com>)
List pgsql-general
Bill Moran <wmoran@potentialtech.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Other questions you'd have to think about: what is the data type of
>> 0xffffffff; what do you do with 0xffffffffffffffffffffffff (too big
>> even for int8).  And it'd likely behoove you to check how Microsoft
>> answers those questions, if you want to point to SQL Server as what's
>> going to keep you out of standards-compatibility problems.  (IOW,
>> if 0x ever did get standardized, the text might well match what
>> SQL Server does.)

> MSSQL seems to use it specifically for the equivalent of BYTEA types,
> and it seems to me that should be how it works in PostgreSQL.

Oh really?  Wow, I'd just assumed you wanted this as a way to write
integers.  That's certainly the use-case I would have personally.
I'm not even sure I like the idea of being able to write byteas without
quotes --- they seem like strings to me, not numbers.

> If an implicit cast from a 4-byte BYTEA to int works now, then it
> should work ... otherwise an explicit cast would be needed, with the
> same behavior if you tried to specify a number that overflows an int
> in any other way.

There's no cast at all from bytea to int.  For one thing, it's quite
unclear what endianness should be assumed for such a cast.  (To get
unsurprising behavior from what you're describing, I think we'd have
to use a big-endian interpretation of the bytea; but that would be
a pain for a lot of other scenarios, or even for this case if you'd
written a bytea of length other than 4 or 8 bytes.)

            regards, tom lane


pgsql-general by date:

Previous
From: Bill Moran
Date:
Subject: Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
Next
From: Bill Moran
Date:
Subject: Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?