Hi,
Here's a patch to remove a copy-and-pasto from xact.h.
--
Thomas Munro
http://www.enterprisedb.com
remove-duplicate-macro.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Sat, Nov 5, 2016 at 9:17 AM, Peter Eisentraut
wrote:
> On 11/3/16 7:17 PM, Michael Paquier wrote:
>> This patch not being complicated, so I would vote for those being
>> addressed now so as they are not forgotten even if there is a FIXME
>> flag added. Perhaps you don't think so, and as that's
On Fri, Nov 4, 2016 at 5:36 PM, Kyotaro HORIGUCHI
wrote:
>> On Tue, Aug 30, 2016 at 1:44 PM, Fujii Masao wrote:
>> > On Tue, Aug 30, 2016 at 1:32 PM, Michael Paquier
>> > wrote:
>> >> On Mon, Aug 29, 2016 at 11:16 PM, Fujii Masao
>> >> wrote:
>> >>> You seem to add another entry for this patch
On Sat, Nov 5, 2016 at 12:58 AM, Peter Eisentraut
wrote:
> The organization of these patches makes sense to me.
>
> On 10/20/16 1:14 AM, Michael Paquier wrote:
>> - 0001, moving all the SHA2 functions to src/common/ and introducing a
>> PG-like interface. No actual changes here.
>
> That's probabl
On Sat, Nov 5, 2016 at 4:15 AM, Tom Lane wrote:
> The callback is "live" the instant you assign to error_context_stack;
> any data it depends on had better be valid before that. In this case
> you're effectively depending on the assumption that
> RelationGetRelationName can't throw an error.
Arg
Peter Eisentraut wrote:
> pg_xlogdump [etc]: Add NLS
So how large are the new .po files?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
I wrote:
> Albe Laurenz writes:
> Anyway, I have prepared a patch along the lines you suggest.
> Pushed, we'll see if the buildfarm likes this iteration any better.
And the answer is "not very much". The Windows builds aren't actually
failing, but they are producing lots of warnings:
lquery_op
On 11/04/2016 04:14 PM, Emre Hasegeli wrote:
The GiST part of it doesn't really work. The current patch compares
oids. We need to change it to compare enumsortorder. I could make it
fail easily:
regression=# create type e as enum ('0', '2', '3');
CREATE TYPE
regression=# alter type e add v
Andrew Dunstan writes:
> The real problem here is that enum_cmp_internal assumes that
> fcinfo->flinfo has been set up, and DirectFunctionCallN doesn't, it sets
> it to NULL.
> The patch below cures the problem. I'm not sure if there is a better
> way. Thoughts?
That may be a good fix for robu
Thomas Munro writes:
> Here's a patch to remove a copy-and-pasto from xact.h.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/31/2016 06:38 AM, Petr Jelinek wrote:
There are some fundamental issues with initial sync that need to be
discussed on list but this one is not known. I'll try to convert this
to test case (seems like useful one) and fix it, thanks for the
report. In meantime I realized I broke the last p
Andrew Dunstan writes:
> On 11/05/2016 11:46 AM, Tom Lane wrote:
>> That may be a good fix for robustness purposes, but it seems pretty horrid
>> from an efficiency standpoint. Where is this call, and should we be
>> modifying it to provide a flinfo?
> I thought of providing an flinfo, but I cou
Thomas Munro writes:
> As noted in a nearby review of some similar code[1], commit 7a2fe9bd
> made merge append very slightly more efficient, but nobody told
> cost_merge_append about the change. I doubt it makes much difference
> to the final cost in practice but I figured it might be worth
> co
I wrote:
> Maybe it'd be all right to commit this anyway, but I'm afraid the most
> common reaction would be "why's it give me this info some of the time,
> but not when I really need it?" I'm inclined to think that an acceptable
> patch will need to provide context for the plan-time and run-time
On 11/05/2016 01:13 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/05/2016 11:46 AM, Tom Lane wrote:
That may be a good fix for robustness purposes, but it seems pretty horrid
from an efficiency standpoint. Where is this call, and should we be
modifying it to provide a flinfo?
I thought
I wrote:
> ... I wonder whether we should
> not try to move in the direction of expanding the set of errors that we
> can provide error cursor info for. One aspect of that would be making
> sure that the text of the current statement is always available at
> runtime. I believe we do always have i
Hi
I checked this code, and it looks well
0. there are not any reason why we would not to implement this feature -
more, the implementation is simple.
1. there was not problem with patching, compilation
2. the original patch is missing new expected result for regress tests,
fixed in attached pa
Jim Nasby writes:
> Attached is a patch that adds support for SRFs and returning composites
> from pl/tcl. This work was sponsored by Flight Aware.
I spent a fair amount of time whacking this around, because I did not
like the fact that you were using the pltcl_proc_desc structs for
call-local d
2016-11-06 2:12 GMT+01:00 Tom Lane :
> Jim Nasby writes:
> > Attached is a patch that adds support for SRFs and returning composites
> > from pl/tcl. This work was sponsored by Flight Aware.
>
> I spent a fair amount of time whacking this around, because I did not
> like the fact that you were us
19 matches
Mail list logo
