Re: [PATCHES] Proposed patch for sequence-renaming problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Proposed patch for sequence-renaming problems
Date: 2005-09-29 02:33:41
Message-ID: 6937.1127961221@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-09-29 02:37:45 Re: [PATCHES] Proposed patch for sequence-renaming problems
Previous Message Bruce Momjian 2005-09-29 02:30:40 Re: Added documentation about caching, reliability

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2005-09-29 02:37:45 Re: [PATCHES] Proposed patch for sequence-renaming problems
Previous Message Bruce Momjian 2005-09-29 02:23:01 Re: [PATCHES] Proposed patch for sequence-renaming problems