Re: [HACKERS] Max size of data types and tuples. (fwd)

>
> >
> > Here's a blast from the past. Shows how I keep those open issues in my
> > mailbox.
> >
> > Forwarded message:
> > > Date: Wed, 29 Jan 1997 13:38:10 -0500
> > > From: aixssd!darrenk(at)abs(dot)net (Darren King)
> > > To: hackers(at)postgreSQL(dot)org
> > > Subject: [HACKERS] Max size of data types and tuples.
>
> Still buried in my 'received' box here too. Can't imagine all the bugs
> and/or issues you have kept in yours.

Not too bad now.

>
>
> > > 1. Clean up the #defines for the max block size. Currently,
> > > there are at least four references to 8192...
>
> Think I found and fixed all of these up.
>
>
> > > __These includes of storage/bufpage.h can be removed.__
>
> Still _quite_ a few #includes that can be removed throughout. First,
> "utils/elog.h" and "util/palloc.h" are include in "postgres.h", so are
> unnecessary to include by themselves since "postgres.h" is include in
> _every_ .c file, correct?

Yes, must be included. Period. Even 3rd party apps.

>
> Also numerous #includes of "storage/bufpage.h" and "storage/fd.h" that are
> unnecessary since the things they were included for (BLCKSZ and SEEK_*) are
> now either in "config.h" or found in a system include file.
>
>
> > > 2. Once the block size issue is taken care of, calculate the
> > > maximum tuple size more accurately.
> ...
> > > 3. When #1 & #2 are resolved, let the textual fields have a max
> > > of (MAX_TUPLE_SIZE - sizeof(int)).
>
> This could be done as soon as I come up with a way of defining the packet
> size for the interfaces since this is the newest limiting factor.
>
> Peter's suggestion of backend functions for getting info might be the way to
> go. It would let the various interfaces get the info they need and would be
> a step towards JDBC and ODBC compliance.

Again, we could just set 3rd party apps to be the maximum tuple size we
will ever have to support.

--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us