[Fwd: Re: [HACKERS] Sequences....]
I think this was intended for the list. :) Clark
-------- Original Message --------
From: Terry Mackintosh <terry@terrym.com>
Subject: Re: [HACKERS] Sequences....
To: Clark Evans <clark.evans@manhattanproject.com>
Hi all
On Wed, 17 Mar 1999, Clark Evans wrote:
0. Remove serial type.
2. Create a new data type serial. I haven't thought idea
out much, and need to investigate it some more. I'm thinking
it would be binary equivilent with the int4 type, and use
most of the existing seqence code, but not put the seqence
name entry in the pg_class system table. Does this sound
like a feasible idea?This dosn't sound all that bad... but I really
wonder what the advantage is.
Well, as I'm starting to use the serial "type" a fair amount, I feel I
should pop up here, for what it's worth:)
I kind of like option 2, maybe serial can even take some paramaters so
that when a dump/reload is done it will know where to take up? and it can
be put in the dump as SERIAL with parameters, instead of as INT4?
Or maybe at the end of the reload it's value can be set, that might be
cleaner.
This brings up a related issue, the fact that a dump file does NOT look
like the origenal script that made the database, that is things like
SERIAL, PRIMARY KEY, REFERENCES table (field), VIEW, and probably some
other things that I missed, none of these things are reconstruced in the
dump file in any intuative way.
All these things can be done in a more round about, more obtuse way, but
the whole point of them (seems to me any way) is to make the source file
easier to read and understand. Am I off base here? if so then what is the
point?
So, working off the last point, should not the dump file, aside from it's
data, look like the origanal script that made the database? so if a table
has a PRIMARY KEY, then instead of an index at the bottom of the dump
file, the table should have ... PRIMARY KEY... in it.
The main reasones I use such constructs are 1. readability and 2.
convienance. As relates to a dump file, #1 is lost and #2 does not
matter, unless maybe one wants to hand edit the dump file for some
reason.
Just my thoughts,
Have a great day
Terry Mackintosh <terry@terrym.com> http://www.terrym.com
sysadmin/owner I'm excited about life! How about YOU!?
Professional Web Hosting and site design to include programming
Proudly powered by R H Linux 4.2, Apache 1.3.x, PHP 3.x, PostgreSQL 6.x
-----------------------------------------------------------------------
Only if you know where you're going can you get there.
Hi Clark and all
On Wed, 17 Mar 1999, Clark Evans wrote:
I think this was intended for the list. :) Clark
Yes, thanks, I've gotten used to another list were the list address is in
the ReplyTo mail header:)
Have a great day
Terry Mackintosh <terry@terrym.com> http://www.terrym.com
sysadmin/owner I'm excited about life! How about YOU!?
Professional Web Hosting and site design to include programming
Proudly powered by R H Linux 4.2, Apache 1.3.x, PHP 3.x, PostgreSQL 6.x
-----------------------------------------------------------------------
Only if you know where you're going can you get there.
This brings up a related issue, the fact that a dump file does NOT look
like the origenal script that made the database, that is things like
SERIAL, PRIMARY KEY, REFERENCES table (field), VIEW, and probably some
other things that I missed, none of these things are reconstruced in the
dump file in any intuative way.All these things can be done in a more round about, more obtuse way, but
the whole point of them (seems to me any way) is to make the source file
easier to read and understand. Am I off base here? if so then what is the
point?So, working off the last point, should not the dump file, aside from it's
data, look like the origanal script that made the database? so if a table
has a PRIMARY KEY, then instead of an index at the bottom of the dump
file, the table should have ... PRIMARY KEY... in it.The main reasones I use such constructs are 1. readability and 2.
convienance. As relates to a dump file, #1 is lost and #2 does not
matter, unless maybe one wants to hand edit the dump file for some
reason.
I don't think we want to make the dump look like the script that created. The
dump is setup to reload the database quickly. That is why the tables and
sequences are created first, then the data is inserted into the tables and
finally the indexes are added last. If we make dump look like the database
script, then the dump-reload will take considerably longer.
I do not have any emperical data at this time to show the above is true, but I
can gather some if someone is interested in it.
-Ryan
P.S. I'm working on a pro's and con's list for the sequences.. then I'm planning
on implimenting a few different options and see what everyone prefers. Not sure
when I'll have this done, this project has become more complex then I first
imagined :)
Import Notes
Resolved by subject fallback