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, back-pa
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 bet
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 environ
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 the
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 u
> 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
>
On Tue, Jun 12, 2018 at 2:04 AM, Tom Lane wrote:
> 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 no
> 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 a
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 just
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 H
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 since different versions (MT/non-MT and
DEBUG/RELEASE?) of CRT ar
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 00:53:
From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
> +#ifndef PGTYPES_FREE
> +#define PGTYPES_FREE
> + extern void PGTYPES_free(void *ptr);
> +#endif
>
> It seems quite strange to repeat this in pgtypes_date.h, pgtypes_interval.h
> and pgtypes_numeric.h. I guess you might not want to intro
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 quite strange to repeat this in
16 matches
Mail list logo