Re: Hex literals

Thomas Lockhart wrote:
> I've got patches to adjust the interpretation of hex literals from an
> integer type (which is how I implemented it years ago to support the
> *syntax*) to a bit string type. I've mentioned this in a previous
> thread, and am following up now.
> 
> One point raised previously is that the spec may not be clear about the
> correct type assignment for a hex constant. I believe that the spec is
> clear on this (well, not really, but as clear as SQL99 manages to get ;)
> and that the correct assignment is to bit string (as opposed to a large
> object or some other alternative).
> 
> I base this on at least one part of the standard, which is a clause in
> the restrictions on the BIT feature (which we already support):
> 
>  31) Specifications for Feature F511, "BIT data type":
>   a) Subclause 5.3, "<literal>":
>    i) Without Feature F511, "BIT data type", a <general literal>
>     shall not be a <bit string literal> or a <hex string
>     literal>.
> 
> This seems to be a hard linkage of hex strings with the BIT type.
> 
> Comments or concerns?
> 

My reading of this was that if there are pairs of <hexit>s, then 
assignment can be to <hex string literal> *or* <binary string literal>, 
but if there are not pairs (i.e. an odd number of <hexit>s) the 
interpretaion must be <hex string literal>. I base this on section 5.3 
<literal>. Peter was the one who pointed this out earlier.

Can BIT be the default but BYTEA be allowed by explicit cast?

Joe