Re: Removal of currtid()/currtid2() and some table AM cleanup - Mailing list pgsql-hackers

From Inoue, Hiroshi
Subject Re: Removal of currtid()/currtid2() and some table AM cleanup
Date
Msg-id 473beb76-642f-359b-ba3b-e8c0c86321b5@dream.email.ne.jp
Whole thread Raw
In response to Re: Removal of currtid()/currtid2() and some table AM cleanup  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Removal of currtid()/currtid2() and some table AM cleanup
List 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




pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: factorial of negative numbers
Next
From: "李杰(慎追)"
Date:
Subject: 回复:how to create index concurrently on partitioned table