Tom Lane wrote:
Here's an updated version of the patch. There's now just one nextval()
function, taking regclass, and backwards compatibility is handled
through an implicit text-to-regclass cast. Existing dumps will not see
any behavioral changes because nextval('foo') will be dumped as
nextval
Here's an updated version of the patch. There's now just one nextval()
function, taking regclass, and backwards compatibility is handled
through an implicit text-to-regclass cast. Existing dumps will not see
any behavioral changes because nextval('foo') will be dumped as
nextval('foo'::text), but
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Well, AFAICT, the only part of the spec we cannot implement is what you
> quote above. Therefore, why can't we support NEXT VALUE FOR seqname and
> reject table creation/alteration which would add more than one reference
> to the same sequence.
And how ar
Gavin Sherry wrote:
> > I don't think we should use the spec syntax until we're prepared to
> > meet the spec semantics, so NEXT VALUE FOR as part of the current patch
> > seems "out".
>
> Well, AFAICT, the only part of the spec we cannot implement is what you
> quote above. Therefore, why can't w
Gavin Sherry wrote:
> > So it's really sort of a magic combination of nextval() and currval().
> > To meet the spec semantics, we'd need some sort of layer over nextval()
> > that would keep track of whether a new value should be obtained or not.
> >
> > I don't think we should use the spec syntax
On Wed, 28 Sep 2005, Tom Lane wrote:
> I wrote:
> > 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).
>
> I have to take t
Tom Lane wrote:
The more I think about it, the more I think that two sets of function
names might not be such an awful idea. next_value(), curr_value(), and
set_value() seem like they'd work well enough. Then we'd just say that
nextval and friends are deprecated except when you need late bin
Bruce Momjian writes:
> I still think we shouldn't be hashing this out during beta, but ...
We're looking at ways to fix some bugs. It's never been the case that
our first-resort response to a bug is "pull out features".
> What would the final nextval() behavior be? ::regclass binding? How
>
Tom Lane wrote:
> I wrote:
> > 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).
>
> I have to take that back. It's not j
I wrote:
> 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).
I have to take that back. It's not just syntactic sugar for next
Bruce Momjian 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 thi
aTom Lane wrote:
> Bruce Momjian 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 w
Bruce Momjian 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
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 au
Attached is a fully-worked-out patch to make SERIAL column default
expressions refer to the target sequence with a "regclass" literal
instead of a "text" literal. Since the regclass literal is actually
just an OID, it is impervious to renamings and schema changes of
the target sequence. This fixe
15 matches
Mail list logo
