(userland comment)
On Fri, Mar 15, 2002 at 01:05:33AM -0800, Vadim Mikheev wrote:
| > But sequences should not be under transaction control. Can you
| > safely rollback a sequence? No! The only way to ensure that would
| ...
| > Placing a restriction on an application that says it must treat the values
| > returned from a sequence as if they might not be committed is absurd.
|
| Why? The fact that you are not able to rollback sequences does not
| necessary mean that you are not required to perform commit to ensure
| permanent storage of changes made to database.
I use sequences to generate message identifiers for a simple
external-to-database message passing system. I also use
them for file upload identifiers. In both cases, if the
external action (message or file upload) succeeds, I commit;
otherwise I roll-back. I assume that the datbase won't give
me a duplicate sequence... otherwise I'd have to find some
other way go get sequences or I'd have duplicate messages
or non-unique file identifiers.
With these changes is this assumption no longer valid? If
so, this change will break alot of user programs.
| And why? Just for convenience of << 1% applications which need
| to use sequences in their own, non-database, external objects?
I think you may be underestimating the amount of "external resources"
which may be associated with a datbase object. Regardless, may of the
database features in PostgreSQL are there for 1% or less of the
user base...
Best,
Clark
--
Clark C. Evans Axista, Inc.
http://www.axista.com 800.926.5525
XCOLLA Collaborative Project Management Software
