Re: Duplicate primary keys/rows

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: Duplicate primary keys/rows
Дата
Msg-id 20051010221527.GC29638@svana.org
обсуждение исходный текст
Ответ на Re: Duplicate primary keys/rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Duplicate primary keys/rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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.

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: weird problem with grants
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Duplicate primary keys/rows