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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PATCHES] Proposed patch for sequence-renaming problems
Дата
Msg-id 200509281535.j8SFZQv04950@candle.pha.pa.us
обсуждение исходный текст
Ответы Re: [PATCHES] Proposed patch for sequence-renaming problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: enhanced pgbench
Следующее
От: Tom Lane
Дата:
Сообщение: Re: \d on database with a lot of tables is slow