Re: [HACKERS] BUG #1883: Renaming a schema leaves inconsistent

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > With the following errors caused by ALTER SCHEMA RENAME, I recommend we
> > remove this feature for 8.1 and revisit it for 8.2.
>
> It's a mistake to blame ALTER SCHEMA RENAME for this problem, as you can
> cause it equally well by renaming the sequence itself, or by moving it
> into another schema with ALTER TABLE SET SCHEMA. Will you also insist
> on disabling the latter new feature?

Sure. (Silly question, silly answer.)

Seriously, you have to consider the likelihood of breakage, and the
surprise factor. If someone moves a sequence to another schema or
renames it, they would assume breakage, but moving all tables/sequences
together would not suggest sequence breakage.

So, below, you are saying that once 8.0.X dumps are loaded into 8.1,
that the renaming of those schemas would succeed, at least for SERIAL,
but not for manual sequence defaults. That seems OK, I guess, in the
hope that people who are creating defaults manually based on sequences
are going to know how to fix things.

---------------------------------------------------------------------------

> I experimented a little bit with defining nextval() and friends as
> taking "regclass" instead of text, and it seems like that works pretty
> nicely for these problems, once you've got the literal in the form of
> regclass (ie, internally an OID). For actual SERIAL columns that
> doesn't seem like a big deal, because the default expression doesn't
> appear literally in dumps (at least not dumps made with a recent version
> of pg_dump). All we'd have to do is tweak the parser to generate a call
> to nextval(regclass) instead of nextval(text) when expanding SERIAL.
>
> For dumps that contain explicit calls, like
> keycol int default nextval('foo'::text)
> I really don't think there is anything much we can do :-( except to
> recommend that people update the default expressions. You'd need to
> change it to
> keycol int default nextval('foo'::regclass)
> to be safe against renamings of 'foo', and I don't see any very good
> way to force that to happen automatically.
>
> I think that a reasonable answer for 8.1 would be to add
> nextval(regclass) (and I guess parallel versions of currval and setval,
> too), leaving the existing text-based functions available, and modifying
> the parser to use nextval(regclass) instead of nextval(text) in SERIAL
> defaults.
>
> In the long run it would be nice to deprecate and eventually remove
> the text-based functions, but I don't see how to do that in the short
> run without introducing an implicit text-to-regclass cast for
> compatibility purposes. That seems a bit risky.
>
> regards, tom lane
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073