Re: [SQL] Column name's length - Mailing list pgsql-sql

> > And I assume it is working fine?
> 
> Yes. It fixes the column length too I think. The following is a psql
> interaction:
> -----
> ssmldb=> create table
> more_than_64_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> (more_than_32_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb boolean ) ;
> CREATE
> ssmldb=> select * from
> more_than_64_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> ;
> more_than_32_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> ---------------------------------------------
> (0 rows)
> ssmldb=> insert into
> more_than_64_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> ( more_than_32_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb ) values ( true ) ;
> INSERT 25353 1
> ssmldb=> select * from
> more_than_64_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> ;
> ^Mmore_than_32_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> ---------------------------------------------
> t
> (1 row)
> -----
> (I did some tests to make sure all the characters are significant. They
> are.)
> 
> Here are the two diffs that up the "name size" from 32 characters to 256
> characters. (Once I get bit, I try to fix things real good so I don't get
> bit again :-))
> -----
> diff  postgresql-6.4.2/src/include/postgres_ext.h postgres-build/src/include/postgres_ext.h
> 34c34
> < #define NAMEDATALEN 32
> ---
> > #define NAMEDATALEN 256
> 37c37
> < #define OIDNAMELEN    36
> ---
> > #define OIDNAMELEN    260
> -----
> diff postgresql-6.4.2/src/include/storage/buf_internals.h postgres-build/src/include/storage/buf_internals.h
> 87c87
> < #define PADDED_SBUFDESC_SIZE  128
> ---
> > #define PADDED_SBUFDESC_SIZE  1024
> -----

PADDED_SBUFDESC_SIZE is gone in 6.5beta, meaning we probably now have
things tuned for NAMEDATALEN directly.

> 
> After this, I did a clean build. I am pretty sure this produces a Postgres
> that *is not* binary compatible with existing databases. You have to do the
> dump/reload thing. (We discovered this issue very early on so I was able to
> trash all my existing databases and start from scratch.)
> 
> I do not know what performance or space usage impact this has. If it is not
> too terrible, this would be a great change to see in a future version of
> Postgres.

Yes, I was thinking this too.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026