Re: [PATCHES] Proposed patch for sequence-renaming problems - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Proposed patch for sequence-renaming problems
Date
Msg-id 6937.1127961221@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Proposed patch for sequence-renaming problems  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [PATCHES] Proposed patch for sequence-renaming problems
Re: [PATCHES] Proposed patch for sequence-renaming problems
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [DOCS] Added documentation about caching, reliability
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Proposed patch for sequence-renaming problems