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....
|
Список | 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 по дате отправления: