Re: [HACKERS] Sequences....

Поиск
Список
Период
Сортировка
От D'Arcy" "J.M." Cain
Тема Re: [HACKERS] Sequences....
Дата
Msg-id m10NDAC-0000cKC@druid.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Sequences....  (Ryan Bradetich <rbrad@hpb50023.boi.hp.com>)
Ответы Re: [HACKERS] Sequences....  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Thus spake Ryan Bradetich
> 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? 

I like it.  I always wondered why serial wasn't a real datatype.  I never
wondered out loud for fear of finding myself with a new project.  :-)

If we are thinking about it, I wonder if we could enhance it somewhat.
Under the current system, the attribute values and underlying method
are divorced but if we make serial a first class type then we can look
at the values, perhaps, when getting the next number.  For example, if
we add a row and specify a number, the system can note that and skip
that number later.  That would certainly fix the dump/restore problem.

Alternatively, maybe we can enforce the serialism of the type.  Even
if the user specifies a value, ignore it and put the next number in
anyway.  Of course, that just brings us back to the dump/restore
problem so...

Do as above but allow the user to specify a number as long as it is
available and is lower than the next number in the series.  When
the restore happens, you need to set the start value to the previous
next value then the inserts can restore with all the old values.  You
can even safely insert new records while the restore is happening.

If we decide to leave things more or less as they are, how about a new
flag for sequences and indexes that sets a row as system generated
rather than user specified?  We can then set that field when a sequence
or index is generated by the system such as for the serial type or
primary keys.  Dump could then be written to ignore these rows on
output.  That would deal with the current issue.

Just some random thought from someone who woke up too early.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.


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

Предыдущее
От: Oleg Broytmann
Дата:
Сообщение: Re: PostgreSQL 6.4.2: float8::text (fwd)
Следующее
От: "Tim Perdue"
Дата:
Сообщение: Re: [HACKERS] Problems with >2GB tables on Linux 2.0