Re: [HACKERS] Inheritance

On 5/22/16 1:37 AM, Jan Johansson wrote: - Allow single (behavior) inheritance (model here is quite a few modern languages, such as C#, D, ...) - Allow multiple declarative inheritance (interface like, the inheritance almost works like this today though) If, with these restrictions (or maybe

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On Mon, May 23, 2016 at 8:50 AM, Andres Freund wrote: > On 2016-05-23 17:19:09 +0800, Craig Ringer wrote: >> Following on from the foreign table batch inserts thread[1], here's a patch >> to add support for pipelining queries into asynchronous batches in libpq. > > Yay! >> I'm

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Hi, On 2016-05-23 17:19:09 +0800, Craig Ringer wrote: > Hi all > Following on from the foreign table batch inserts thread[1], here's a patch > to add support for pipelining queries into asynchronous batches in libpq. Yay! > I'm measuring 300x (not %) performance improvements doing batches on >

Re: [HACKERS] Inheritance

On Mon, May 23, 2016 at 10:21 AM, Jim Nasby wrote: > On 5/22/16 1:37 AM, Jan Johansson wrote: >> >> - Allow single (behavior) inheritance (model here is quite a few modern >> languages, such as C#, D, ...) >> - Allow multiple declarative inheritance (interface like,

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Fri, May 20, 2016 at 1:41 PM, David G. Johnston wrote: > How does the relatively new FILTER clause play into this, if at all? My interpretation of the standard is that FILTER is not allowable for a window function, and IGNORE|RESPECT NULLS is not allowable for an

Re: [HACKERS] Calling json_* functions with JSONB data

On 2016-05-23 18:55, Peter van Hardenberg wrote: I talked this over with Andrew who had no objections and suggested I float it on the list before writing a patch. Looks pretty straightforward, just a few new data rows in pg_proc.h. Anyone have any concerns or suggestions? What about cases

Re: [HACKERS] Calling json_* functions with JSONB data

Peter van Hardenberg writes: > I talked this over with Andrew who had no objections and suggested I float > it on the list before writing a patch. Looks pretty straightforward, just a > few new data rows in pg_proc.h. I think you might find that you need to add new C function entry

Re: [HACKERS] Changed SRF in targetlist handling

David Fetter writes: > On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote: >> This seems a bridge too far to me. It's just way too common to do >> "select generate_series(1,n)". We could tell people they have to >> rewrite to "select * from generate_series(1,n)", but it

Re: [HACKERS] Calling json_* functions with JSONB data

On Mon, May 23, 2016 at 12:55 PM, Peter van Hardenberg wrote: > Hi there, > > I noticed it was very easy to accidentally call the json_* form of JSON > manipulation functions with jsonb data as input. This is pretty > sub-optimal, since it involves rendering the jsonb then reparsing

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Mon, May 23, 2016 at 12:01 PM, Jeff Davis wrote: > On Fri, May 20, 2016 at 1:41 PM, David G. Johnston > wrote: > > How does the relatively new FILTER clause play into this, if at all? > > My interpretation of the standard is that FILTER is not

Re: [HACKERS] Parallel safety tagging of extension functions

Tom Lane wrote: > Michael Paquier writes: > > On Sat, May 21, 2016 at 6:16 PM, Andreas Karlsson wrote: > >> My immediate thought is first doing an UPDATE of pg_proc and then updating > >> the catcache with CREATE OR REPLACE with the new arguments.

Re: [HACKERS] Changed SRF in targetlist handling

Andres Freund writes: > discussing executor performance with a number of people at pgcon, > several hackers - me included - complained about the additional > complexity, both code and runtime, required to handle SRFs in the target > list. Yeah, this has been an annoyance for

Re: [HACKERS] Calling json_* functions with JSONB data

On Mon, May 23, 2016 at 11:14 AM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, May 23, 2016 at 12:55 PM, Peter van Hardenberg wrote: > >> Hi there, >> >> I noticed it was very easy to accidentally call the json_* form of JSON >> manipulation functions with jsonb

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote: > This seems a bridge too far to me. It's just way too common to do > "select generate_series(1,n)". We could tell people they have to > rewrite to "select * from generate_series(1,n)", but it would be far > more polite to do that for

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 1:44 PM, David Fetter wrote: > On Mon, May 23, 2016 at 01:36:57PM -0400, Tom Lane wrote: > > David Fetter writes: > > > On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote: > > >> This seems a bridge too far to me. It's just way

Re: [HACKERS] Calling json_* functions with JSONB data

Marko Tiikkaja writes: > On 2016-05-23 18:55, Peter van Hardenberg wrote: >> Anyone have any concerns or suggestions? > What about cases like json_whatever($1) which previously worked but > will now be ambiguous? (Or will they somehow not be ambiguous?) Good point, that would

Re: [HACKERS] It's seems that the function "do_text_output_multiline" does not suit for format "line1\nline2\n...lineN".

David Rowley writes: > On 20 May 2016 at 19:13, Hao Lee wrote: >> Today, I am do some works on adding some customized featues to PostgreSQL >> 9.6 beta1. But, when i do some output to psql using the fuction >> "do_text_output_multiline" with the

Re: [HACKERS] Latent cache flush hazard in RelationInitIndexAccessInfo

Michael Paquier writes: > On Fri, Sep 11, 2015 at 11:29 AM, Robert Haas wrote: >> On Wed, Sep 9, 2015 at 3:00 PM, Tom Lane wrote: >>> The specific reason there's a problem is that there's a disconnect between >>>

[HACKERS] Calling json_* functions with JSONB data

Hi there, I noticed it was very easy to accidentally call the json_* form of JSON manipulation functions with jsonb data as input. This is pretty sub-optimal, since it involves rendering the jsonb then reparsing it and calling the json_* form of the function. Fortunately, this seems quite easy

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

I wrote: >> ... the pg_dump process has crashed with a SIGPIPE without printing >> any message whatsoever, and without coming anywhere near finishing the >> dump. > Attached is a proposed patch for this. It reverts exit_horribly() to > what it used to be pre-9.3, ie just print the message on

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 01:36:57PM -0400, Tom Lane wrote: > David Fetter writes: > > On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote: > >> This seems a bridge too far to me. It's just way too common to do > >> "select generate_series(1,n)". We could tell people they

Re: [HACKERS] Changed SRF in targetlist handling

David Fetter writes: > On Mon, May 23, 2016 at 01:36:57PM -0400, Tom Lane wrote: >> David Fetter writes: >>> How about making "TABLE generate_series(1,n)" work? It's even >>> shorter in exchange for some cognitive load. >> No thanks --- the word after TABLE

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

Andreas Seltenreich wrote: > There was one instance of this PANIC when testing with the regression db > of master at 50e5315. > > , > | WARNING: specified item offset is too large > | PANIC: failed to add BRIN tuple > | server closed the connection unexpectedly > ` > > It is

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote: > Andres Freund writes: >> discussing executor performance with a number of people at pgcon, >> several hackers - me included - complained about the additional >> complexity, both code and runtime, required

Re: [HACKERS] Parallel safety tagging of extension functions

Michael Paquier writes: > On Sat, May 21, 2016 at 6:16 PM, Andreas Karlsson wrote: >> My immediate thought is first doing an UPDATE of pg_proc and then updating >> the catcache with CREATE OR REPLACE with the new arguments. Does that work? >> Is

Re: [HACKERS] Parallel safety tagging of extension functions

Alvaro Herrera writes: > Tom Lane wrote: >> You'd have to alter the index opfamily to disconnect the function from it, >> drop/recreate the function, then re-add it to the opfamily. Kind of icky, >> but probably better than the alternatives. > What happens if the

[HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

On Sat, May 21, 2016 at 5:03 PM, Peter Geoghegan wrote: > On Sat, May 21, 2016 at 4:28 PM, wrote: >> ERROR: XX000: unrecognized node type: 920 >> LOCATION: raw_expression_tree_walker, nodeFuncs.c:3410 >> >> I expected the query run successfully and

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

Peter Geoghegan writes: > On Mon, May 23, 2016 at 12:22 PM, Tom Lane wrote: >> It seems unlikely to me that recursing into the name lists is helpful >> here: those are not going to contain any data that is interpretable >> without context. Did you have a

Re: [HACKERS] Changed SRF in targetlist handling

Joe Conway writes: > I would be in favor of rewriting it to a LATERAL, but that would not be > backwards compatible entirely either IIUC. It could be made so, I think, but it may be more trouble than it's worth; see my previous message. > I'll also note that, unless I missed

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera wrote: > Tom Lane wrote: > > Joe Conway writes: > > > > I'll also note that, unless I missed something, we also have to > consider > > > that the capability to pipeline results is still only available

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

On Mon, May 23, 2016 at 12:48 PM, Tom Lane wrote: >> I saw no reason to avoid the extra cycles. A noticeable omission has a >> cost: it gets noticed. Given this code path is likely to hardly ever >> be hit, this mechanical approach seemed best. That's all. > > I agree that

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

On Mon, May 23, 2016 at 1:55 PM, Tom Lane wrote: > Um, I think not --- you need the case cited by the OP, namely an INSERT > ON CONFLICT in a CTE in a SelectStmt. If we'd had any of those in the > regression tests, we'd have found the bug, but we don't; and it's not > an

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: > On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote: > > Andres Freund writes: > >> discussing executor performance with a number of people at pgcon, > >> several hackers - me included -

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote: > On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: >> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote: >> > Andres Freund writes: >> >> discussing executor performance

Re: [HACKERS] Changed SRF in targetlist handling

Tom Lane wrote: > Joe Conway writes: > > I'll also note that, unless I missed something, we also have to consider > > that the capability to pipeline results is still only available in the > > target list. > > Yes, we would definitely want to improve nodeFunctionscan.c to

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 02:39:54PM -0500, Merlin Moncure wrote: > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote: > > On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: > >> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote: > >> > Andres

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 4:05 PM, David Fetter wrote: > On Mon, May 23, 2016 at 02:39:54PM -0500, Merlin Moncure wrote: > > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote: > > > On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: > > >> On

Re: [HACKERS] Changed SRF in targetlist handling

Merlin Moncure writes: > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote: >> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: >>> +1 on removing LCM. >> As a green field project, that would make total sense. As a thing >> decades in,

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

Peter Geoghegan writes: > Attached patch fixes this issue by adding the appropriate > raw_expression_tree_walker handler. This isn't the first quasi-utility > node to need such a handler, so the fix is simple. It seems unlikely to me that recursing into the name lists is helpful

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

Peter Geoghegan writes: > On Mon, May 23, 2016 at 12:48 PM, Tom Lane wrote: >> Also, related to this complaint though not this patch, it's disturbing >> that this oversight wasn't detected long ago. My first thought was to add >> some conditionally-compiled

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

On Mon, May 23, 2016 at 12:22 PM, Tom Lane wrote: > It seems unlikely to me that recursing into the name lists is helpful > here: those are not going to contain any data that is interpretable > without context. Did you have a reason to do that? I saw no reason to avoid the

Re: [HACKERS] Changed SRF in targetlist handling

On 05/23/2016 12:39 PM, Merlin Moncure wrote: > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote: >> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: >>> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote: Andres Freund

Re: [HACKERS] Calling json_* functions with JSONB data

Great question, Marko. If you can point me towards an example I'll take a look, but I'll proceed with the current understanding and suggestions and see what people have to say. On Mon, May 23, 2016 at 10:47 AM, Marko Tiikkaja wrote: > On 2016-05-23 18:55, Peter van Hardenberg

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote: > Merlin Moncure writes: > > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote: > >> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: > >>> +1 on removing LCM. > > >> As

Re: [HACKERS] Calling json_* functions with JSONB data

Peter van Hardenberg writes: > Great question, Marko. If you can point me towards an example I'll take a > look, but I'll proceed with the current understanding and suggestions and > see what people have to say. I believe Marko's just complaining about the case for unknown-type

Re: [HACKERS] Changed SRF in targetlist handling

"David G. Johnston" writes: > On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera > wrote: >> Ah, so that's what "pipeline results" mean! I hadn't gotten that. I >> agree; Abhijit had a patch or a plan for this, a long time ago ... > ​Is

Re: [HACKERS] Typo in 001_initdb.pl

On Mon, May 23, 2016 at 5:05 PM, Tom Lane wrote: > Michael Paquier writes: >> I just bumped into the following typo for $subject: >> - 'role names cannot being with "pg_"'); >> + 'role names cannot begin with "pg_"'); > > Pushed, thanks.

Re: [HACKERS] LSN as a recovery target

On 24 May 2016 at 09:12, Michael Paquier wrote: > Hi all, > > Today somebody has pointed me out that it could be interesting to be > able to recovery up to a given LSN position. One argument behind that > was to allow a maximum of things to recover up to the point

Re: [HACKERS] BTREE_BUILD_STATS build is broken

On Mon, May 23, 2016 at 8:09 PM, Tom Lane wrote: > Does it appear to compile without that? It does. The only thing that's absent is the pgrminclude directive, which is of course just a C comment. > (More generally, is there a better answer for that problem?) My unpublished

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 24 May 2016 at 00:00, Michael Paquier wrote: > > Did you consider the use of simple_list.c instead of introducing a new > mimic as PGcommandQueueEntry? It would be cool avoiding adding new > list emulations on frontends. > I'd have to extend simple_list to add a

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Craig Ringer writes: > On 24 May 2016 at 00:00, Michael Paquier wrote: >> Did you consider the use of simple_list.c instead of introducing a new >> mimic as PGcommandQueueEntry? It would be cool avoiding adding new >> list emulations on

Re: [HACKERS] LSN as a recovery target

On Mon, May 23, 2016 at 6:25 PM, Craig Ringer wrote: > On 24 May 2016 at 09:12, Michael Paquier wrote: >> >> Hi all, >> >> Today somebody has pointed me out that it could be interesting to be >> able to recovery up to a given LSN position. One

[HACKERS] BTREE_BUILD_STATS build is broken

The attached patch fixes the BTREE_BUILD_STATS build. Looks like 65c5fcd353a859da9e61bfb2b92a99f12937de3b broke this. That commit was made back in January, so no backpatch is required. -- Peter Geoghegan From 06d2150ff20dfa3e6fbc579a9e41ff3f6487 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan

Re: [HACKERS] Inheritance

On 5/23/16 11:05 AM, Merlin Moncure wrote: Postgres doesn't work that way, and the documentation disclaims this: "Note: Although inheritance is frequently useful, it has not been integrated with unique constraints or foreign keys, which limits its usefulness. See Section 5.8 for more detail."

Re: [HACKERS] Inheritance

On 05/23/2016 03:05 PM, Tom Lane wrote: > Jim Nasby writes: >> I don't see why partitioning complicates fixing these issues. ISTM it's >> the exact same complaint for both inheritance and partitioning. > > My feeling about it is that we need to provide a partitioning

Re: [HACKERS] Typo in 001_initdb.pl

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Mon, May 23, 2016 at 5:05 PM, Tom Lane wrote: > > Michael Paquier writes: > >> I just bumped into the following typo for $subject: > >> - 'role names cannot being with "pg_"'); > >> +

Re: [HACKERS] Typo in 001_initdb.pl

Michael Paquier writes: > I just bumped into the following typo for $subject: > - 'role names cannot being with "pg_"'); > + 'role names cannot begin with "pg_"'); Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] BTREE_BUILD_STATS build is broken

On Mon, May 23, 2016 at 4:41 PM, Tom Lane wrote: > Pushed, thanks. Thanks. If BTREE_BUILD_STATS needs a "tcopprot.h pgrminclude ignore" within nbtree.c, then ISTM that the similar include directive within nbtsort.c ought to receive the same treatment. -- Peter Geoghegan

[HACKERS] LSN as a recovery target

Hi all, Today somebody has pointed me out that it could be interesting to be able to recovery up to a given LSN position. One argument behind that was to allow a maximum of things to recover up to the point where a relation block got corrupted by a specific record because of a broken segment. So

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 24 May 2016 at 00:00, Michael Paquier wrote: > On Mon, May 23, 2016 at 8:50 AM, Andres Freund > wrote: > >> This should be very useful for optimising FDWs, Postgres-XC, etc. > > > > And optimizing normal clients. > > > > Not easy, but I'd be

Re: [HACKERS] BTREE_BUILD_STATS build is broken

Peter Geoghegan writes: > If BTREE_BUILD_STATS needs a "tcopprot.h pgrminclude ignore" within > nbtree.c, then ISTM that the similar include directive within > nbtsort.c ought to receive the same treatment. Does it appear to compile without that? (More generally, is there a

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 24 May 2016 at 00:00, Michael Paquier wrote: > On Mon, May 23, 2016 at 8:50 AM, Andres Freund wrote: > > > yay^2. > > I'll follow this mood. Yeha. BTW, I've publushed the HTML-ified SGML docs to

Re: [HACKERS] Inheritance

On 24 May 2016 at 00:05, Merlin Moncure wrote: > > This feature was very much a product of the time, at the height of the > "Object Relational" fad. The trend for postgres has been in the exact > opposite direction, towards the SQL standard. Further complicating > matters,

Re: [HACKERS] Calling json_* functions with JSONB data

On 5/23/16 11:55 AM, Peter van Hardenberg wrote: Fortunately, this seems quite easy to resolve by taking advantage of our ability to add json_*(jsonb) form of the functions. Another issue no one has mentioned is functions that return JSON/JSONB. IMO those should NOT be overloaded, because

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

Peter Geoghegan writes: > What I meant is that I think naively adding the choke-point for a > top-level SelectStmt would do the job (although perhaps we could do > better). I wasn't suggesting that we'd avoid recursing from there; > only that we could reasonably avoid recursing

Re: [HACKERS] Inheritance

Joe Conway writes: > But then again, maybe we need to start with a clear notion of what > problems people are trying to solve when they use partitions. At least > some of the historic reasons are no longer valid. That's true. Just because people want to have a gazillion

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

I wrote: > Peter Geoghegan writes: >>> If that sounds like a plausible choke-point, the next question is what >>> to use to enable the debug test. I propose "#ifdef COPY_PARSE_PLAN_TREES" >>> since that enables similar sanity checking for other parts of >>> backend/nodes/, and

Re: [HACKERS] Calling json_* functions with JSONB data

On Mon, May 23, 2016 at 4:37 PM, Tom Lane wrote: > Peter van Hardenberg writes: > > Great question, Marko. If you can point me towards an example I'll take a > > look, but I'll proceed with the current understanding and suggestions and > > see what people have

Re: [HACKERS] Changed SRF in targetlist handling

On 05/23/2016 02:37 PM, David G. Johnston wrote: > ​But then I don't get Joe's point - if its an implementation detail why > should it matter if rewriting the SRF-in-tlist to be laterals changes > execution from a serial to an interleaved​ implementation. Plus, Joe's > claim: "the capability to

Re: [HACKERS] Inheritance

Jim Nasby writes: > On 5/23/16 11:05 AM, Merlin Moncure wrote: >> This feature was very much a product of the time, at the height of the >> "Object Relational" fad. The trend for postgres has been in the exact >> opposite direction, towards the SQL standard. Further

Re: [HACKERS] BTREE_BUILD_STATS build is broken

Peter Geoghegan writes: > The attached patch fixes the BTREE_BUILD_STATS build. Looks like > 65c5fcd353a859da9e61bfb2b92a99f12937de3b broke this. That commit was > made back in January, so no backpatch is required. Pushed, thanks. regards, tom lane --

Re: [HACKERS] Inheritance

Tom Lane wrote: > My feeling about it is that we need to provide a partitioning feature > that doesn't rely on the current notion of inheritance at all. We've > heard from multiple users who want to use large numbers of partitions, > enough that simply having a separate relcache entry for each

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

Peter Geoghegan writes: > On Mon, May 23, 2016 at 4:11 PM, Tom Lane wrote: >> And after further thought, I decided that that was penny-wise and >> pound-foolish; it's more readable if the #define is just an independent >> pg_config_manual.h entry. The only

Re: [HACKERS] Calling json_* functions with JSONB data

I'll look into it, thanks for the explanation. On Mon, May 23, 2016 at 1:37 PM, Tom Lane wrote: > Peter van Hardenberg writes: > > Great question, Marko. If you can point me towards an example I'll take a > > look, but I'll proceed with the current

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

On Mon, May 23, 2016 at 4:11 PM, Tom Lane wrote: > And after further thought, I decided that that was penny-wise and > pound-foolish; it's more readable if the #define is just an independent > pg_config_manual.h entry. The only work it'd save is the need to update > a

Re: [HACKERS] Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE

On Mon, May 23, 2016 at 4:27 PM, Tom Lane wrote: >> You also have to be aware of the new thing, which a lot of hackers >> will not be, if awareness of COPY_PARSE_PLAN_TREES is anything to go >> by. > > I doubt that anybody ever enables that in manual builds anyway. > The

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 4:42 PM, Tom Lane wrote: > "David G. Johnston" writes: > > On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > >> Ah, so that's what "pipeline results" mean! I hadn't gotten that. I

Re: [HACKERS] Calling json_* functions with JSONB data

On Mon, May 23, 2016 at 5:38 PM, Jim Nasby wrote: > On 5/23/16 11:55 AM, Peter van Hardenberg wrote: > >> Fortunately, this seems quite easy to resolve by taking advantage of our >> ability to add json_*(jsonb) form of the functions. >> > > Another issue no one has

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

I wrote: >> There's another class of parallel worker core dumps when testing master >> with sqlsmith. In these cases, the following assertion fails for all >> workers simulataneously: >> >> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File: >> "shm_mq.c", Line: 386) > > I no

Re: [HACKERS] foreign table batch inserts

On 20 May 2016 at 23:18, Craig Ringer wrote: > On 20 May 2016 at 15:35, Craig Ringer wrote: > > >> >> You can, however, omit Sync from between messages and send a series of >> protocol messages, like >> >>

[HACKERS] PATCH: Batch/pipelining support for libpq

Hi all Following on from the foreign table batch inserts thread[1], here's a patch to add support for pipelining queries into asynchronous batches in libpq. Attached, and also available at https://github.com/2ndQuadrant/postgres/tree/dev/libpq-async-batch (subject to rebasing and force pushes).

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

Amit Kapila writes: > Earlier problems were due to the reason that some unsafe/restricted > expressions were pushed below Gather node as part of target list whereas in > the plan6, it seems some unsafe node is pushed below Gather node. It will > be helpful if you can share the offending query?

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

On Mon, May 23, 2016 at 2:19 PM, Andreas Seltenreich wrote: > > I wrote: > >> There's another class of parallel worker core dumps when testing master > >> with sqlsmith. In these cases, the following assertion fails for all > >> workers simulataneously: > >> > >> TRAP: