(2013/07/18 23:54), Robert Haas wrote:
On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@gmail.com> writes:
1. snapshot-error-v1.patch introduces a new special snapshot, called
SnapshotError.  In the cases where we set SnapshotNow as a sort of
default snapshot, this patch changes the code to use SnapshotError
instead.  This affects scan->xs_snapshot in genam.c and
estate->es_snapshot in execUtils.c.  This passes make check-world, so
apparently there is no code in the core distribution that does this.
However, this is safer for third-party code, which will ERROR instead
of seg faulting.  The alternative approach would be to use
InvalidSnapshot, which I think would be OK too if people dislike this
approach.

FWIW, I think using InvalidSnapshot would be preferable to introducing
a new concept for what's pretty much the same thing.

Andres voted the other way on the previous thread.  I'll wait and see
if there are any other opinions.  The SnapshotError concept seemed
attractive to me initially, but I'm not as excited about it after
seeing how it turned out, so maybe it's best to do it as you suggest.

With that done, the only remaining uses of SnapshotNow in our code
base will be in currtid_byreloid() and currtid_byrelname().  So far no
one on this list has been able to understand clearly what the purpose
of those functions is, so I'm copying this email to pgsql-odbc in case
someone there can provide more insight.

I had the idea they were used for a client-side implementation of WHERE
CURRENT OF.  Perhaps that's dead code and could be removed entirely?

It's been reported that ODBC still uses them.

Though PostgreSQL's TID is similar to Orale's ROWID, it is transient
and changed after update operations unfortunately. I implemented
the currtid_xx functions to supplement the difference. For example

        currtid(relname, original tid)

(hopefully) returns the current tid of the original row when it is
updated.

regards,
Hiroshi Inoue



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to