Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Kouber Saparev <postgresql(at)saparev(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [HACKERS] BUG #1883: Renaming a schema leaves inconsistent
Date: 2005-09-27 19:35:33
Message-ID: 200509271935.j8RJZXL05901@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2005-09-27 22:33:25
Subject: Re: Gerbil build farm failure
Previous:From: Bruce MomjianDate: 2005-09-27 19:21:41
Subject: Re: Open items list for 8.1

pgsql-bugs by date

Next:From: Kevin GrittnerDate: 2005-09-27 23:04:53
Subject: BUG #1916: selection criteria from one outer join on clause applied to other joins
Previous:From: Alvaro HerreraDate: 2005-09-27 19:27:36
Subject: Re: BUG #1913: select into a table missing a row part 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group