I'd think this settles things for now: ----- Forwarded message from Tom Lane <[EMAIL PROTECTED]> -----
> Subject: Re: [GENERAL] XMIN semantic at peril ? > > Karsten Hilbert <[EMAIL PROTECTED]> writes: > > How likely is XMIN (or equivalent) to become invisible to > > SQL level user space ? > > No one has suggested this. I suppose the argument could be made that > the system columns are an unwarranted intrusion on users' column > namespace, but we'd probably handle that by demoting them to > second-class citizens, not hiding them entirely --- there are far too > many apps that rely on ctid, for instance, and I think some that are > doing like you do with xmin. So as long as you don't create a user > column named xmin in your tables, you could expect to access the system > column. > > > How likely is XMIN (or equivalent) to NOT change on each > > successful (write) transaction commit anymore ? > > No chance of that, unless we abandon MVCC for something else, which > again seems highly unlikely. > > One question I'd have though is whether "freezing" of old tuples is > likely to confuse your app. That process might get more aggressive > in the future (it already is more aggressive in 8.2 than before, > depending on where vacuum_freeze_min_age is set). > > The only argument you cited that seems impressive to me is the one > about it being a Postgres-ism. Are you willing to have GNUmed tied > tightly to Postgres? > > regards, tom lane ----- End forwarded message ----- -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
