Re: Duplicate primary keys/rows - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Duplicate primary keys/rows
Date
Msg-id 20051010221527.GC29638@svana.org
Whole thread Raw
In response to Re: Duplicate primary keys/rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Duplicate primary keys/rows  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Mon, Oct 10, 2005 at 05:28:17PM -0400, Tom Lane wrote:
> I recall having proposed that we stop storing explicit pg_attribute
> entries for system columns, which would make this sort of change easier
> to make, and would save a pretty considerable amount of space in
> pg_attribute too.  (In the present regression database, about 45% of the
> rows in pg_attribute are for system columns; that might be overly high
> for real-world DBs though.)  But people were a bit worried about what
> might break.

In catalog/heap.c there already is a SystemAttributeByName() to do the
legwork. Seems to me all you'd need to do is check just as you're about
to fail on "attribute not found".

If you actually look at scanRTEForColumn() in parser/parse_relation.c
it actually checks to see if a column name could be a system column
name, *before* looking it up in the catalog. Remove the catalog test
(except for OID obviously) and it'd sail right through. It'd be
interesting to see what happened...

Given that internally, they're referred to by number, it might not be
so bad. As usual, external clients might get confused if they're not
there...
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Attachment

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: weird problem with grants
Next
From: Tom Lane
Date:
Subject: Re: Duplicate primary keys/rows