Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

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,

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

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

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

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

Re: [HACKERS] Mention column name in error messages

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

Re: [HACKERS] btree_gin and btree_gist for enums

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

Re: [HACKERS] Mention column name in error messages

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

Re: [HACKERS] Tweak cost_merge_append to reflect 7a2fe9bd?

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

Re: [HACKERS] btree_gin and btree_gist for enums

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

Re: [HACKERS] Logical Replication WIP

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

Re: [HACKERS] MinSizeOfXactInvals defined twice

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:

Re: [HACKERS] btree_gin and btree_gist for enums

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

Re: [HACKERS] btree_gin and btree_gist for enums

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

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

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

Re: [HACKERS] [COMMITTERS] pgsql: pg_xlogdump: Add NLS

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)

Re: [HACKERS] Mention column name in error messages

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

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

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

Re: [HACKERS] Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

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

Re: [HACKERS] add more NLS to bin

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

[HACKERS] MinSizeOfXactInvals defined twice

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:

Re: [HACKERS] Contents of "backup_label" and "*.backup" in pg_wal location

> On Fri, Nov 4, 2016 at 7:04 PM, Venkata B Nagothi > wrote: > > Sure. I will look at the possibility of using XLOG_BACKUP_END in my > patch. > > I am looking at the possibility of keeping the backup_label at source > until > > pg_stop_backup() > > is executed and then write