Re: [HACKERS] Sequences....
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Sequences.... |
Дата | |
Msg-id | 18685.921689657@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Sequences.... ("D'Arcy" "J.M." Cain <darcy@druid.net>) |
Ответы |
Re: [HACKERS] Sequences....
(Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Sequences.... ("D'Arcy" "J.M." Cain <darcy@druid.net>) |
Список | pgsql-hackers |
"D'Arcy" "J.M." Cain <darcy@druid.net> writes: > 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. A binary-equivalent type does seem like a handier way to represent SERIAL than what we are doing. You still need a way to find the associated sequence object, though, so a table mapping from table-and-column to sequence OID is still necessary. (Unless we were to use the atttypmod field for the column to hold the sequence object's OID? Seems a tad fragile though, since there's no way to update an atttypmod field in an existing table.) I don't like the idea of not putting the sequence name into pg_class. That would mean that the sequence object is not directly accessible for housekeeping operations. If you do that, you'd have to invent all-new ways to do the following:* currval, setval, nextval (yes there are scenarios where a direct nextval on the sequenceis useful)* dump and reload the sequence in pg_dump > 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. I don't like that at *all*. > 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. I think better would be that the sequence value is silently forced to be at least as large as the inserted number, whenever a specific number is inserted into a SERIAL field. That would ensure we never generate duplicates, but not require keeping any extra state. > 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. 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 ... regards, tom lane
В списке pgsql-hackers по дате отправления: