aTom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I looked over the patch, and while it does fix the problem for SERIAL, I
> > am concerned about expecting users to user ::regclass in normal usage,
> > and I am concerned about adding something we will have to support in the
> > future when we come up with a better solution. Why is regclass not
> > being used automatically?
>
> If we provide both nextval(text) and nextval(regclass), then the parser
> will interpret "nextval('something')" as nextval(text) because that's
> the more preferred resolution of an unknown-type literal. The only way
> to make regclass be used "automatically" would be to remove the
> text-input variant. That is where I want to go eventually, but it seems
> pretty risky to jump there in one step. The proposed patch adds
> regclass-based functions alongside the existing functionality, so that
> people can migrate as they choose; it does not open any risks of
> breaking cases that work now.
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.
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. 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?
--
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, Pennsylvania 19073