>
> 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@abs.net (Darren King)
> > To: hackers@postgreSQL.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.
> > 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?
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.
darrenk
