Re: [PATCHES] Proposed patch for sequence-renaming problems
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] Proposed patch for sequence-renaming problems |
Дата | |
Msg-id | 200509290237.j8T2bjJ14039@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch for sequence-renaming problems (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am thinking we should hard-code something in the backend so if the > > function oid is nextval/currval/setval, we strip off any text casting > > internally. > > NO. No bloody way ... that is far dirtier than any other proposal > that's been made in this thread. I don't even want to think about > what strange corner-case semantics that might create. Well, it would be if ((oid == xxx || oid == yyy) && cast_exists) remove cast; Seems safe to me. > >> So on the whole I like leaving nextval() as-is and introducing a > >> separate function next_value(regclass). > > > I disagree. nextval() is too embedded in people's thinking to make them > > change > > Why? And what's your evidence for this? You could equally well argue > that the fact that nextval takes a text argument is too embedded to > change. 99% of people using nextval think (or don't care) that it is early binding. I see no reason to re-educate people just to keep nextval() as late binding. > > when we have the ability to have it do the _right_ _thing_, > > We have no ability to make it do what you think is the right thing, > at least not without introducing kluges that are certain to come back > to haunt us. Well, then, let's leave it all for 8.2 where we can discuss/test and come up with a plan. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: