On Sun, Nov 22, 2020 at 08:11:21PM +0900, Michael Paquier wrote:
> Okay, here you go with the attached. If there are any other comments,
> please feel free.
Hearing nothing, applied this one after going through the ODBC driver
code again this morning. Compatibility is exactly the same for
currti
On Sat, Nov 21, 2020 at 09:39:28PM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> So, what you are basically saying is to switch currtid_byreloid() to
>> become a function local to tid.c. And then have just
>> currtid_byrelname() and currtid_for_view() call that, right?
>
> Yeah, that sound
Michael Paquier writes:
> So, what you are basically saying is to switch currtid_byreloid() to
> become a function local to tid.c. And then have just
> currtid_byrelname() and currtid_for_view() call that, right?
Yeah, that sounds about right.
regards, tom lane
On Sat, Nov 21, 2020 at 01:13:35PM -0500, Tom Lane wrote:
> Considering that we're preserving this only for backwards compatibility,
> I doubt that changing the signature is a good idea. It maybe risks
> breaking something, and the ODBC driver is hardly going to notice
> any improved ease-of-use.
Hi,
+1 for getting rid of whatever we can without too much trouble.
On 2020-11-21 13:13:35 -0500, Tom Lane wrote:
> Michael Paquier writes:
> > Indeed, this could go. There is a recursive call for views, but in
> > order to maintain compatibility with that we can just remove one
> > function an
Michael Paquier writes:
> Indeed, this could go. There is a recursive call for views, but in
> order to maintain compatibility with that we can just remove one
> function and move the second to use a regclass as argument, like the
> attached, while removing setLastTid(). Any thoughts?
Consideri
On Fri, Nov 20, 2020 at 09:50:08PM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> What about cutting the cake in two and just remove
>> currtid() then?
>
> +1. That'd still let us get rid of setLastTid() which is
> the ugliest part of the thing, IMO.
Indeed, this could go. There is a recu
Michael Paquier writes:
> What about cutting the cake in two and just remove
> currtid() then?
+1. That'd still let us get rid of setLastTid() which is
the ugliest part of the thing, IMO.
regards, tom lane
On Fri, Nov 20, 2020 at 11:53:11AM -0500, Tom Lane wrote:
> Yeah, if pgODBC were not using it at all then I think it'd be fine
> to get rid of, but if it still contains calls then we cannot.
> The suggestion upthread that those calls might be unreachable
> is interesting, but it seems unproven.
Ye
Peter Eisentraut writes:
> On 2020-09-03 12:14, Michael Paquier wrote:
>> Opinions are welcome about the arguments of upthread.
> It appears that currtid2() is still used, so we ought to keep it.
Yeah, if pgODBC were not using it at all then I think it'd be fine
to get rid of, but if it still co
On 2020-09-03 12:14, Michael Paquier wrote:
On Fri, Jun 26, 2020 at 01:11:55PM +0900, Michael Paquier wrote:
From what I can see on this thread, we could just remove currtid() per
the arguments of the RETURNING ctid clause supported since PG 8.2, but
it would make more sense to me to just remov
On Fri, Jun 26, 2020 at 01:11:55PM +0900, Michael Paquier wrote:
> From what I can see on this thread, we could just remove currtid() per
> the arguments of the RETURNING ctid clause supported since PG 8.2, but
> it would make more sense to me to just remove both currtid/currtid2()
> at once.
The
On Thu, Jun 25, 2020 at 10:14:00PM +0900, Inoue, Hiroshi wrote:
> I seem to have invalidated KEYSET-DRIVEN cursors used in positioned-update
> test. It was introduced by the commit 4a272fd but was invalidated by the
> commit 2be35a6.
>
> I don't object to the removal of currtid(2) because keyset-
Hi,
I seem to have invalidated KEYSET-DRIVEN cursors used in
positioned-update test .
It was introduced by the commit 4a272fd but was invalidated by the
commit 2be35a6.
I don't object to the removal of currtid(2) because keyset-driven
cursors in psqlodbc are changed into static cursors in ma
Hi Inoue-san,
On Wed, Jun 24, 2020 at 05:20:42PM +0900, Inoue, Hiroshi wrote:
> Where do you test, on Windows or on *nix?
> How do you test there?
I have been testing the driver on macos only, with various backend
versions, from 11 to 14.
Thanks,
--
Michael
signature.asc
Description: PGP signa
Hi Michael,
Where do you test, on Windows or on *nix?
How do you test there?
regards,
Hiroshi Inoue
On 2020/06/24 11:11, Michael Paquier wrote:
On Tue, Jun 23, 2020 at 02:02:33PM +0900, Michael Paquier wrote:
Actually, while reviewing the code, the only code path where we use
currtid2() invol
On Tue, Jun 23, 2020 at 02:02:33PM +0900, Michael Paquier wrote:
> Actually, while reviewing the code, the only code path where we use
> currtid2() involves positioned_load() and LATEST_TUPLE_LOAD. And the
> only location where this happens is in SC_pos_reload_with_key(), where
> I don't actually
On Tue, Jun 23, 2020 at 01:29:06PM +0900, Michael Paquier wrote:
> Sorry, but I am not quite sure what is the relationship between
> UseDeclareFetch and currtid2()? Is that related to the use of
> SQL_CURSOR_KEYSET_DRIVEN? The only thing I can be sure of here is
> that we never call currtid2() in
On Mon, Jun 15, 2020 at 08:50:23PM +0900, Inoue, Hiroshi wrote:
> Sorry for the reply.
No problem, thanks for taking the time.
> On 2020/06/08 15:52, Michael Paquier wrote:
>> On Fri, Jun 05, 2020 at 10:25:00PM +0900, Inoue, Hiroshi wrote:
>>We have two
>> problems here then:
>> 1) We cannot
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 un
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
On 2020/06/05 15:22, Michael Paquier wrote:
On Wed, Jun 03, 2020 at 10:10:21PM +0900, Inoue, Hiroshi wrote:
On 2020/06/03 11:14, Michael Paquier wrote:
I have been looking at the ODBC driver and the need for currtid() as
well as currtid2(), and as mentioned already in [1], matching with my
lo
On Wed, Jun 03, 2020 at 10:10:21PM +0900, Inoue, Hiroshi wrote:
> On 2020/06/03 11:14, Michael Paquier wrote:
>> I have been looking at the ODBC driver and the need for currtid() as
>> well as currtid2(), and as mentioned already in [1], matching with my
>> lookup of things, these are actually not
On Thu, Jun 04, 2020 at 10:59:05AM -0700, Andres Freund wrote:
> What's the point of that change? I think the differentiation between
> heapam_handler.c and heapam.c could be clearer, but if anything, I'd
> argue that heap_get_latest_tid is sufficiently low-level that it'd
> belong in heapam.c.
We
Hi,
On 2020-06-03 11:14:48 +0900, Michael Paquier wrote:
> I would like to remove those two functions and the surrounding code
> for v14, leading to some cleanup:
> 6 files changed, 326 deletions(-)
+1
> While on it, I have noticed that heap_get_latest_tid() is still
> located within heapam.c,
Hi,
On 2020/06/03 11:14, Michael Paquier wrote:
Hi all,
I have been looking at the ODBC driver and the need for currtid() as
well as currtid2(), and as mentioned already in [1], matching with my
lookup of things, these are actually not needed by the driver as long
as we connect to a server ne
I wrote:
> It looks like table_beginscan_tid wouldn't need to be exported anymore
> either.
Ah, scratch that, I misread it.
regards, tom lane
Michael Paquier writes:
> I would like to remove those two functions and the surrounding code
> for v14, leading to some cleanup:
+1
> While on it, I have noticed that heap_get_latest_tid() is still
> located within heapam.c, but we can just move it within
> heapam_handler.c.
It looks like tabl
28 matches
Mail list logo
