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

From Bruce Momjian
Subject Re: [PATCHES] Proposed patch for sequence-renaming problems
Date
Msg-id 200509281535.j8SFZQv04950@candle.pha.pa.us
Whole thread Raw
Responses Re: [PATCHES] Proposed patch for sequence-renaming problems
List pgsql-hackers
Tom Lane wrote:
> > It is
> > only the last one where recommending regclass helps, but is it worth
> > improving sequence/schema renaming by exposing and recommending a
> > ::regclass syntax that will go away as soon as we fix this properly?
> 
> Please explain what you think a "proper" fix is.  I think this patch is
> a proper fix.  I see no better alternative that we might implement
> later.
> 
> The only other thing that's been discussed is the SQL2003 syntax
>     NEXT VALUE FOR sequencename
> but this is in fact just syntactic sugar for something functionally
> equivalent to nextval('sequencename'::regclass).  It cannot completely
> replace all uses of the nextval function, because only a constant table
> name can appear.
> 
> Hmm ... given the proposed patch, it would indeed take only a few more
> lines in gram.y to support the NEXT VALUE FOR syntax ...

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.  This seems like the only way
sequence naming will be sustainable from release to release.  Saying
"use ::regclass" over and over again, when 99% of users should be using
it for nextval in default clauses, is going to get very tiring.

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.

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


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: enhanced pgbench
Next
From: Tom Lane
Date:
Subject: Re: \d on database with a lot of tables is slow