Thread: [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 :)