From: Thomas Munro
> Ok, back-patched.
Thank you very much!
> It seems like the other patch[1] might need the same treatment,
right?
I believe so, because that patch is based on the same cause.
Regards
MauMau
On Mon, Jun 25, 2018 at 8:16 PM, Tsunakawa, Takayuki
wrote:
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
>> However I also don't see a problem to back-patch it, I don't see
>> a problem on such difference between versions.
>
> Thank you, Horiguchi-san and Robert.
Ok,
At Mon, 25 Jun 2018 08:16:10 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FA241F9@G01JPEXMBYT05>
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> > However I also don't see a problem to back-patch it, I don't see
> > a problem on such difference
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> However I also don't see a problem to back-patch it, I don't see
> a problem on such difference between versions.
Thank you, Horiguchi-san and Robert.
> .. Is there any means to find the library version on the
> installed
Hello. Thank you for commiting this, Thomas.
At Mon, 18 Jun 2018 07:25:13 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FA1BCD9@G01JPEXMBYT05>
> > > I want some remedy for older releases. Our customer worked around this
> > problem by getting a libpq connection in
On Mon, Jun 11, 2018 at 10:04 AM, Tom Lane wrote:
> Given that this has been broken since forever, and there've been
> no complaints before now, I do not think the case for back-patching
> is strong enough to justify the problems it would cause. Just
> put it in v11 and be done.
I'm not sure I
> On Tue, Jun 12, 2018 at 1:09 PM, Tsunakawa, Takayuki
> wrote:
> > My colleague is now preparing a patch for that, which adds a function
> ECPGFreeSQLDA() in libecpg.so. That thread is here:
> >
> https://www.postgresql.org/message-id/25C1C6B2E7BE044889E4FE8643A58BA9
> 63A42097@G01JPEXMBKW03
>
> From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
> I would like to get this committed soon, but I'm not sure about backpatching
> -- see below. Here's a new version with a couple of minor changes:
Thank you for taking care of this patch.
> 1. Small changes to the documentation.
I
Thomas Munro writes:
> One question I have is whether it is against project policy to
> backport a new file and a new user-facing function.
Given that this has been broken since forever, and there've been
no complaints before now, I do not think the case for back-patching
is strong enough to
On Mon, Mar 26, 2018 at 6:07 PM, Kyotaro HORIGUCHI
wrote:
> At Sun, 25 Mar 2018 22:15:52 +0900, "MauMau" wrote in
>
>> And thank you for your review. All modifications are done.
>
> Thank you for the new version. I marked this as "Ready for
> Committer" with one change.
Hi Tsunakawa-san and
At Sun, 25 Mar 2018 22:15:52 +0900, "MauMau" wrote in
> And thank you for your review. All modifications are done.
Thank you for the new version. I marked this as "Ready for
Committer" with one change.
- Windows requires this
From: Kyotaro HORIGUCHI
The objective of this patch looks reasonable and this doesn't
affect ecpg applications except for the problematic case that
happens only on Windows. So the points here are only the
documentation, the new function name and the how we should place
the new defintion.
I think
Hello.
The objective of this patch looks reasonable and this doesn't
affect ecpg applications except for the problematic case that
happens only on Windows. So the points here are only the
documentation, the new function name and the how we should place
the new defintion.
At Mon, 5 Feb 2018
On Fri, Feb 2, 2018 at 3:47 PM, Tsunakawa, Takayuki
wrote:
> The fix is to add PGTYPES_free() in libpgtypes.dll, just like libpq has
> PQfreemem() described here:
+#ifndef PGTYPES_FREE
+#define PGTYPES_FREE
+ extern void PGTYPES_free(void *ptr);
+#endif
It seems
14 matches
Mail list logo