> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 21 October 2004 15:26
> To: Dave Page
> Cc: PgAdmin Hackers
> Subject: Re: [pgadmin-hackers] Sequence bug
>
> Dave Page wrote:
> >
> > Hmm, it's not though is it, because (assuming a basic new sequence
> > with no odd values set), start = 1, min = 1, max = whatever.
> > PostgreSQL will error if you try to set it to zero. The
> closest thing
> > to zero is to set it to 1 and unset is_called.
> >
> > I would say the least confusing behaviour would be to use
> >
> > setval('foo', x, true);
>
> I don't agree.
> If you CREATE SEQUENCE foo START 100, nextval will return
> 100. RESTART 100 (7.4/8.0) will lead to the same behaviour,
> so setval('foo', 100,
> false) would be the equivalent.
Yes, but pgAdmin displays Current Value = 100. If I do a SELECT
nextval('foo'), then I would expect to get 101 if the current value =
100. It just seems wrong somehow...
> Actually, currval() would return just 100 too, whether is
Not in 7.3. currval() will return "ERROR: foobar.currval is not yet
defined in this session" until you've done at least one nextval().
Following which, currval()'s behaviour will be what you would expect of
course. Maybe the thing to do is simply do the same in pga, but in a
more friendly way, rather than display what is effectively a bogus
value?
> foo.isCalled is true or false, i.e. you can't know from that
> which value will be returned by nextval(), 100 or 101.
> We *could* calculate this when displaying the sequence
> property, todo for 1.4?
Yeah, think so.
/D
