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
> 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?
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-07-30 18:05:57|
|Subject: Re: WAL file location |
|Previous:||From: Lamar Owen||Date: 2002-07-30 16:57:55|
|Subject: Re: WAL file location|