Karsten Hilbert <Karsten.Hilbert@xxxxxxx> 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 of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
