Re: Hex literals

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hex literals
Date: 2002-07-30 21:42:34
Message-ID: Pine.LNX.4.44.0207301919270.1928-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart writes:

> 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.

You'll also find in 5.3 Conformance Rule 9)

9) Without Feature T041, "Basic LOB data type support", conforming
Core SQL language shall not contain any <binary string literal>.

which is an equally solid linkage.

I might also add that the rules concerning the absence of a feature do not
determine what happens in presence of a feature. ;-)

Let's think: We could send a formal interpretation request to the
standards committee. (They might argue that there is no ambiguity,
because the target type is always known.) Or we could check what other
database systems do.

In any case, I'd rather create a readable syntax for blob'ish types (which
the current bytea input format does not qualify for) rather than mapping
hexadecimal input to bit types, which is idiosyncratic.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-07-30 21:43:22 Re: START TRANSACTION
Previous Message Peter Eisentraut 2002-07-30 21:42:00 Re: Password sub-process ...