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

From Thomas Kellerer
Subject Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
Date
Msg-id mjpq6b$e98$1@ger.gmane.org
Whole thread Raw
In response to Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
List pgsql-general
Tom Lane wrote on 21.05.2015 19:57:
> One large concern about doing anything like this is whether future
> versions of the SQL standard might blindside us with some
> not-terribly-compatible interpretation of that syntax.  If we do something
> that is also in Oracle or DB2 or one of the other big boys, then we can
> probably rely on the assumption that they'll block anything really
> incompatible from becoming standardized ;-).


The SQL standard already specifies the format for "binary strings":

<binary string literal> ::=
     X <quote> [ <space>... ] [ { <hexit> [ <space>... ] <hexit> [ <space>... ] }... ] <quote>
        [ { <separator> <quote> [ <space>... ] [ { <hexit> [ <space>... ]
        <hexit> [ <space>... ] }... ] <quote> }... ]

<hexit> ::=
     <digit> | A | B | C | D | E | F | a | b | c | d | e | f


The data type for such a literal is somewhat "undefined":

     It is implementation-defined whether the declared type of a <binary string literal>
     is a fixed-length binary string type, a variable-length binary string type,
     or a binary large object string type

But the above syntax seems to be only supported by H2, HSQLDB and Apache Derby.



pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
Next
From: rob stone
Date:
Subject: Re: Server tries to read a different config file than it is supposed to