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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > What I am primarily worried about in your patch is the exposure of
> > ::regclass as a recommended way of doing things. I know we can
> > discourage its us later, but once people start using something, it is
> > hard to change.
>
> Why shouldn't it be a recommended way of doing things? It is certainly
> far better than the existing text-argument way.

::regclass just seems too low-level to be something we should recommend.
We have tried to move away from :: casts in the default clauses. What
really concerns me is that for the most common case, where you want oid
binding at object creation time, you need to use ::regclass, while
ideally we would have the ::regclass behavior be the default. (I don't
have problems with people seeing ::regclass after the object is created,
and I think it does help clarify that is it not a string that is stored.

> > Right now, we have three cases, SERIAL, DEFAULT with no-schema seqname,
> > and DEFAULT with schema-specified seqname. If we just do regclass
> > internally for SERIAL, we don't have any user-visible change, except for
> > the psql \d display of the default.
>
> > The second case already works because there is no class name.
>
> No, it really wouldn't "work" at all. It's unsafe if the user changes
> the search path for example, and it certainly doesn't handle any of the
> renaming or change-of-schema cases.

True, but the rename of the schema case would work.

> > 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 ...

Yes, I was thinking of something cleaner-looking. I have no trouble
fixing ALTER SCHEMA RENAME, but I would like it to be something that is
well thought out that will last unchanged from release to release,
rather than something hastily done. Just the fact you are considering
making ::regclass the default for nextval() in a later release means it
isn't a long-term solution, in terms of syntax that the user has to use
_now_, but not later.

--
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