Re: [HACKERS] Sequences....

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ryan Bradetich <rbrad(at)hpb50023(dot)boi(dot)hp(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Sequences....
Date: 1999-03-18 02:33:51
Message-ID: 19678.921724431@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ryan Bradetich <rbrad(at)hpb50023(dot)boi(dot)hp(dot)com> writes:
>>>> Yes, it'd be nice to think about fixing up primary-key implicit indexes
>>>> while we are at it --- they have some of the same problems as SERIAL ...

> I'm not following this... When a table is dropped, all the indexes for
> that table get dropped. The indexes are associated with a table,
> whereas the sequences are just sequences not associated with a table.
> Am I understanding the issue correctly?

It's mainly a pg_dump issue: can pg_dump identify such an index as
having come from a PRIMARY KEY spec rather than a separate CREATE INDEX
command? This goes back to the complaint about pg_dump not being able
to fully reconstruct the logical connections in a database.

A related issue is inheritance: if I say PRIMARY KEY in the definition
of a table, and then make a child table that inherits from that table,
I'd expect the child's field to act like a PRIMARY KEY too --- in other
words it should have a unique index created for it. Right now I don't
believe that that happens.

What it all comes down to is that mapping these structures into "lower
level" objects without remembering the higher-level structure isn't
fully satisfactory. We need an explicit, persistent representation of
the PRIMARY KEY attribute. In that way it's the same problem as SERIAL.
The best solutions might be different, however.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 1999-03-18 02:34:16 Re: [HACKERS] Subqueries and indexes
Previous Message Tom Lane 1999-03-18 02:25:01 Re: OID vs SERIAL? (Was: Re: [HACKERS] Sequences....)