Re: [HACKERS] Max size of data types and tuples. (fwd)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Max size of data types and tuples. (fwd) |
Дата | |
Msg-id | 199801220249.VAA25988@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Max size of data types and tuples. (fwd) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: