Thread: No support for int8 sized binary/hex literals

No support for int8 sized binary/hex literals

From
pgsql-bugs@postgresql.org
Date:
Steffen Hulegaard (9sch1@txl.com) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
No support for int8 sized binary/hex literals

Long Description
     The B'111...' and X'1F...' SQL92 literal syntax is limited to
int4 sized literals.  Any attempt to use an int8 sized literal
> int4/32-bit word size fails.  This makes it impossible to specify
many int8 sized bit patterns as column default values.  It makes
it impossible to even insert > 32bit sized binary/hex values.
Failure to support SQL92 literals for int8 types dramatically
limits and/or complicates the use of int8 bit/nibble/byte composed
values (bit fields, nibble/byte patterns, etc.)

Sample Code
/* $Id$
 +--------------------------------------------------------------------
 | No Copyright.  Public Domain.
 +--------------------------------------------------------------------
 |
 | bug5.sql         32 bit limit on SQL92 numeric literals
 |
 | Major Annoyance:  Any attempt to use SQL92 string literals
 |                   (B'0101...' or X'1fa945...') whose values
 |                   exceed the 32 bit limit fail.  This dramatically
 |                   limits and/or complicates usage of int8 types
 |                   for either bit fields or byte/nibble fields.
 |                   You cannot define default values for
 |                   int8 fields with binary or hex literals due
 |                   to this limitation.
 |
 | Environment ----------------------------------------------------
 | RedHat 6.2
 | select version();
 |    PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
 | # rpm -qi postgresql-7.0.2-2
 | Name        : postgresql                   Relocations: /usr
 | Version     : 7.0.2                             Vendor: The Ramifordistat
 | Release     : 2                             Build Date: Mon 12 Jun 2000 02:21:35 PM PDT
 | Install date: Fri 04 Aug 2000 11:40:39 AM PDT      Build Host: utility.wgcr.org
 | Group       : Applications/Databases        Source RPM: postgresql-7.0.2-2.src.rpm
 | Size        : 7431735                          License: BSD
 | Packager    : Lamar Owen <lamar.owen@wgcr.org>
 | URL         : http://www.postgresql.org/
 | Summary     : PostgreSQL client programs and libraries.
 |
 | 02/17/2000  SC Hulegaard  Created.
 + -------------------------------------------------------------------  */

CREATE TABLE test_num_literals (
  foo                    INT4,
  bigfoo                 INT8
);

/* try what works */
insert into test_num_literals (foo)    values ( X'04040404');

/* get close to limit - this works too */
insert into test_num_literals (foo)    values ( X'040404040');

/* demonstrate that it works for int8 type attributes too */
insert into test_num_literals (bigfoo) values ( X'040404040');

/* step beyond the 32 bit limit - this does *NOT* work - FAILS! */
insert into test_num_literals (bigfoo) values ( X'0404040404');

/* try to establish an int8 bit pattern - FAILS! */
insert into test_num_literals (bigfoo) values ( X'0404040404040404');

/* review what did work */
select * from test_num_literals;

DROP TABLE test_num_literals ;


No file was uploaded with this report

Re: No support for int8 sized binary/hex literals

From
Peter Eisentraut
Date:
>      The B'111...' and X'1F...' SQL92 literal syntax is limited to
> int4 sized literals.  Any attempt to use an int8 sized literal
> > int4/32-bit word size fails.  This makes it impossible to specify
> many int8 sized bit patterns as column default values.  It makes
> it impossible to even insert > 32bit sized binary/hex values.
> Failure to support SQL92 literals for int8 types dramatically
> limits and/or complicates the use of int8 bit/nibble/byte composed
> values (bit fields, nibble/byte patterns, etc.)

The B'111...' and X'1F...' SQL92 literal syntax is not for integer types
at all.  The upcoming version 7.1 will implement the BIT and BIT VARYING
types, which have virtually unlimited length.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/