> 
> 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

Sun, 11 Jan 1998 21:04:15 -0500
darrenk@insightdist.com (Darren King)
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@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.

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@candle.pha.pa.us

Wed, 14 Jan 1998 10:29:30 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Max size of data types and tuples. (fwd)
On Wed, 14 Jan 1998, Bruce Momjian wrote:

> > 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.

Currently, were returning some defaults based on the 8K block size.

Probably for these, we may be able to get away with the values we are
setting. However, there are a few things that I think we will still need
to implement as functions.

-- 
Peter T Mount  petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk


Wed, 14 Jan 1998 19:36:59 +0000 (GMT)
Peter T Mount <psqlhack@maidast.demon.co.uk>
Re: [HACKERS] Max size of data types and tuples. (fwd)
> 
> On Wed, 14 Jan 1998, Bruce Momjian wrote:
> 
> > > 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.
> 
> Currently, were returning some defaults based on the 8K block size.
> 
> Probably for these, we may be able to get away with the values we are
> setting. However, there are a few things that I think we will still need
> to implement as functions.

OK, let's decide soon, so people can be ready for Feb 1.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Wed, 14 Jan 1998 16:27:24 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Max size of data types and tuples. (fwd)
On Wed, 14 Jan 1998, Bruce Momjian wrote:
> > On Wed, 14 Jan 1998, Bruce Momjian wrote:
> > 
> > > > 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.
> > 
> > Currently, were returning some defaults based on the 8K block size.
> > 
> > Probably for these, we may be able to get away with the values we are
> > setting. However, there are a few things that I think we will still need
> > to implement as functions.
> 
> OK, let's decide soon, so people can be ready for Feb 1.

I'm going to sort out what needs to be done to get us as close to
compliance as possible over the next couple of days. Hopefully, we can
decide on some of them then.

-- 
Peter T Mount  petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk


Thu, 15 Jan 1998 19:25:43 +0000 (GMT)
Peter T Mount <psqlhack@maidast.demon.co.uk>
Re: [HACKERS] Max size of data types and tuples. (fwd)
Are we done with these issues, or are you still working on them, or is
Peter working on this?

> 
> > 
> > > 
> > > 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.
> 
> 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@candle.pha.pa.us
> 
> 


-- 
Bruce Momjian
maillist@candle.pha.pa.us

Wed, 21 Jan 1998 21:49:00 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Max size of data types and tuples. (fwd)