Re: Removal of currtid()/currtid2() and some table AM cleanup

From: "Inoue, Hiroshi" <h-inoue(at)dream(dot)email(dot)ne(dot)jp>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Hiroshi Saito <hiroshi(at)winpg(dot)jp>
Subject: Re: Removal of currtid()/currtid2() and some table AM cleanup
Date: 2020-06-15 11:50:23
Message-ID: 473beb76-642f-359b-ba3b-e8c0c86321b5@dream.email.ne.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry for the reply.

On 2020/06/08 15:52, Michael Paquier wrote:
> On Fri, Jun 05, 2020 at 10:25:00PM +0900, Inoue, Hiroshi wrote:
>> Keyset-driven cursors always detect changes made by other applications
>> (and themselves). currtid() is necessary to detect the changes.
>> CTIDs are changed by updates unfortunately.
> You mean currtid2() here and not currtid(), right?

Yes.

> We have two
> problems here then:
> 1) We cannot actually really remove currtid2() from the backend yet
> without removing the dependency in the driver, or that may break some
> users.

I think only ODBC driver uses currtid2().

> 2) The driver does not include tests for that stuff yet.

SQLSetPos(.., .., SQL_REFRESH, ..) call in positioned-update-test passes
the stuff
 when 'Use Declare/Fetch' option is turned off. In other words,
keyset-driven cursor
is not supported when 'Use Declare/Fetch' option is turned on. Probably
keyset-driven
cursor support would be lost regardless of 'Use Declare/Fetch' option
after the
removal of currtid2().

> --
> Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 李杰 (慎追) 2020-06-15 12:15:05 回复:how to create index concurrently on partitioned table
Previous Message Ashutosh Bapat 2020-06-15 11:15:25 Re: factorial of negative numbers