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 6927.1127922793@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
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Just to follow up, I agree we can't totally replace all instances of
> nextval() with regclass because regclass requires a constant string, but
> I would like to have the regclass behavior with simple syntax and
> require people who want "late binding" of the sequence name to use some
> extra syntax, like ::text or something.

That would require a considerably more invasive change, AFAICS: remove
the text-input version of nextval() and introduce an implicit coercion
from text to regclass to avoid breaking existing dumps.  I'd prefer not
to mess with that during beta, because there'd be nontrivial risk of
breaking existing behaviors.  Because the proposed patch just adds on
new functions and doesn't change the behavior of existing DEFAULT
clauses, I don't think it can break anything.

However, we could certainly add the NEXT VALUE FOR syntax if that will
satisfy your concern about syntax.

> The other question is whether we should be playing with this at all
> during beta.  Should we just disable ALTER SCHEMA RENAME and return to
> this during 8.2?  I am worried these side missions will delay our final
> release of 8.1.

I'm prepared to argue that this is a bug fix, not only for ALTER SCHEMA
RENAME but for some very long-standing problems with renaming of
sequences.  As I said before, you are seriously mistaken to consider
that disabling ALTER SCHEMA RENAME would eliminate the problem.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: enhanced pgbench
Next
From: "Qingqing Zhou"
Date:
Subject: Re: Database file compatability