Re: [Gnumed-devel] address@hidden: Re: [GENERAL] XMIN semantic at peril ?]

[Syan Tan]

having slept on it,  I was going to argue, but I've posted the query to
psql-novice . I was thinking the idiom is that the originally selected
value of an item needs to be stored apart from the client's current 
value for an item, and at the beginning of every update transaction,
the old value needs to be re-selected, and compared to the original 
stored selected value, and if it has changed, then this would be
equivalent to xmin checking on an item, without actually sticking
one's fingers into postgresql's guts.

On Fri Oct 12  8:04 , Tim Churches <address@hidden> sent:

>Syan Tan wrote:
>> you wouldn't need xmin checking if more effort was made by the postgresql 
>> people
>> to cater
>> for caching interactive clients , which would  be a significant group of pg
customers
>> i would have thought. e.g something like using savepoints, atomic 
>> commit/resume
>> transaction , the ability to read committed in order to reload , and the 
>> ability
>> to poll for change notification, so that you don't need another thread to 
>> listen
>> for notified changes, and you can use read committed to refresh cached 
>> values.
>> Too much to ask for ? 
>
>Have you actually asked the Postgres maintainers for these things? What
>was their response? No point just complaining on this list - you have to
>voice your needs on the Postgres lists.
>
>Tim C