Skip site navigation (1) Skip section navigation (2)

Re: Re: BIT/BIT VARYING status

From: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Re: BIT/BIT VARYING status
Date: 2000-10-31 11:51:34
Message-ID: 39FEB246.A4467197@albourne.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut wrote:
> 
> Adriaan Joubert writes:
> 
> > > 2. We don't handle <bit string> and <hex string> literals correctly;
> > > the scanner converts them into integers which seems quite at variance
> > > with the spec's semantics.
> >
> > This is still a problem that needs to be fixed.
> 
> I have gotten the B'1001'-style syntax to work, but the zpbit_in function
> rejects the input.  You need to change the *_in functions to accept input
> in the form of a string of only 1's and 0's.  Also, the output functions
> should print 1's and 0's.
> 
> I'm somewhat confused about the <hex string>s; according to the standard
> they might also be a BLOB literal.  I'd say we get the binary version
> working first, and then wonder about this.

Peter, I think it is a problem if the B or X are dropped from the input,
as that is the only way to determine whether it is a binary or hex
string. Isn't it possible to just remove the quotes, or even do nothing?
The current code expects a string of the form  Bxxxxx  or Xyyyyy. If the
quotes are left in, I can easily modify the code, but guessing whether
the string 1001 is hex or binary is an issue, and I seem to recall that
the SQL standard requires both to be valid input.

Also, on output, shouldn't we poduce B'xxxx' and X'yyyyy' to conform
with the input strings?

Adriaan

In response to

Responses

pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2000-10-31 13:14:15
Subject: AW: LIMIT in DECLARE CURSOR: request for comments
Previous:From: Gunnar R|nningDate: 2000-10-31 11:50:53
Subject: Re: how good is PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group