| 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: | Whole Thread | Raw Message | 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
| 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 |