Also, why is the nextval ::text casting output by pg_dump anyway? ---------------------------------------------------------------------------
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. > > >> 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. > > > 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. > > regards, tom lane > -- 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, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
