From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump future problem. |
Date: | 2003-05-05 15:22:28 |
Message-ID: | 27926.1052148148@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> Good point. It's only in the source code. I thought I had updated the docs
> as well...
Actually, I think the sequence of events was that we neglected to remove
the statement in the source code when we fixed the documentation.
3-parameter setval is documented because it solves a problem that users
have --- pg_dump is not the only application that needs to do this.
> My recollection is that setting is_called is more fragile than just setting
> the sequence value, so it not wise to use in general.
Doesn't look that way to me; we're setting several fields of the
sequence record no matter what. Perhaps your recollection predates
Vadim's last rewrite of the sequence code?
> I'm not actually suggesting starting over. Just presenting a nicer
> interface and fixing a bug in the process, rather than building yet another
> user-visible function as a band-aid solution.
But the proposed "nicer interface" *introduces* a bug, namely the
inability to preserve is_called, which is exactly the pg_dump bug
that 3-parameter setval was invented to fix. I do not want to go
backwards in the name of a "nicer interface".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2003-05-05 15:31:58 | Re: Why are triggers semi-deferred? |
Previous Message | Stephan Szabo | 2003-05-05 15:20:23 | Re: Why are triggers semi-deferred? |