Re: [HACKERS] [PATCH] A hook for session start

2017-11-03 Thread Michael Paquier
On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello wrote: >> Passing the database name and user name does not look much useful to >> me. You can have access to this data already with CurrentUserId and >> MyDatabaseId. > > This way we don't need to convert oid to

Re: [HACKERS] Exclude pg_internal.init from base backup

2017-11-03 Thread Michael Paquier
On Fri, Nov 3, 2017 at 4:04 PM, Petr Jelinek wrote: > Not specific problem to this patch, but I wonder if it should be made > more clear that those files (there are couple above of what you added) > are skipped no matter which directory they reside in. Agreed, it is

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-03 Thread Claudio Freire
On Fri, Nov 3, 2017 at 4:30 PM, Tom Lane wrote: > Claudio Freire writes: >> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote: >>> BTW, the originally given test case shows no measurable improvement >>> on my box. > >> I did manage

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

2017-11-03 Thread Tom Lane
Paul Ramsey writes: >> Whether I get a parallel aggregate seems entirely determined by the number >> of rows, not the cost of preparing those rows. > This is true, as far as I can tell and unfortunate. Feeding tables with > 100ks of rows, I get parallel plans, feeding

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

2017-11-03 Thread Paul Ramsey
Just clarifying myself a little, since I made a dumb error partway through. On Thu, Nov 2, 2017 at 10:09 AM, Paul Ramsey wrote: > I'm working on a custom aggregate, that generates a serialized data > format. The preparation of the geometry before being formatted is

Re: [HACKERS] How to implement a SP-GiST index as a extension module?

2017-11-03 Thread Alexander Korotkov
On Fri, Nov 3, 2017 at 12:37 PM, Connor Wolf < conn...@imaginaryindustries.com> wrote: > EDIT: That's actually exactly how the example I'm working off of works. > DERP. The SQL is > > CREATE TYPE vptree_area AS > ( > center _int4, > distance float8 > ); > > CREATE OR REPLACE FUNCTION

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-11-03 Thread Alexander Korotkov
On Wed, Nov 1, 2017 at 5:55 AM, Masahiko Sawada wrote: > On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov > wrote: > > On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada > > wrote: > >> > >> On Mon, Oct 30, 2017 at 10:16

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-11-03 Thread Alexander Korotkov
On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote: > On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov > wrote: > > However, from user prospective of view, current behavior of > > hot_standby_feedback is just broken, because it both increases

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Jeff Janes
On Fri, Nov 3, 2017 at 1:34 PM, Tom Lane wrote: > Jeff Janes writes: > > With this v3 patch (assuming this is the one you just committed > > as ec42a1dcb30de235b252f6d4) am now getting make check failures. > > There's a followup commit already :-( > >

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-03 Thread Tom Lane
I wrote: > Have not looked at the 0002 patch yet. I looked at that one, and it seems to be a potential win with no downside, so pushed. (I tweaked it slightly to avoid an unnecessary conflict with the test patch I posted earlier.) regards, tom lane -- Sent via

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Tom Lane
Jeff Janes writes: > With this v3 patch (assuming this is the one you just committed > as ec42a1dcb30de235b252f6d4) am now getting make check failures. There's a followup commit already :-( regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-11-03 Thread Andres Freund
On November 4, 2017 1:22:04 AM GMT+05:30, Alvaro Herrera wrote: >Peter Geoghegan wrote: >> Andres Freund wrote: > >> > Staring at the vacuumlazy hunk I think I might have found a related >bug: >> > heap_update_tuple() just copies the old xmax to

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-11-03 Thread Tom Lane
Michael Paquier writes: > On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila wrote: >> On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote: >>> I've marked the CF entry closed. However, I'm not sure if we're quite >>> done with this

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-11-03 Thread Peter Geoghegan
Alvaro Herrera wrote: He means that the tuple that heap_update moves to page 1 (which will no longer be processed by vacuum) will contain a multixact that's older than relminmxid -- because it is copied unchanged by heap_update instead of properly checking against age

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Jeff Janes
Hi Alvaro, With this v3 patch (assuming this is the one you just committed as ec42a1dcb30de235b252f6d4) am now getting make check failures. brin_summarize_range is returning unexpected values. CentOS6, PostgreSQL 11devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat

Re: [HACKERS] LDAPS

2017-11-03 Thread Thomas Munro
On Sat, Nov 4, 2017 at 2:05 AM, Thomas Munro wrote: > That > said, I've only tested the attached lightly on FreeBSD + OpenLDAP and > don't know if it'll work elsewhere. Oops, that version's TAP test was a little too dependent on my system's ldap.conf file. Here's

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Alvaro Herrera
Alvaro Herrera wrote: > I think your argument is sensible for some uses (where people run manual > VACUUM after loading data) but not others (where people just use manual > VACUUM in place of autovacuuming -- because they don't trust autovac, or > the schedule isn't convenient, or whatever other

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-11-03 Thread Alvaro Herrera
Peter Geoghegan wrote: > Andres Freund wrote: > > Staring at the vacuumlazy hunk I think I might have found a related bug: > > heap_update_tuple() just copies the old xmax to the new tuple's xmax if > > a multixact and still running. It does so without verifying liveliness >

Re: [HACKERS] ucs_wcwidth vintage

2017-11-03 Thread Tom Lane
Alvaro Herrera writes: > Thomas Munro wrote: >> src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth >> implementation that originally arrived in commit df4cba68, but the >> upstream code[1] apparently continued evolving and there have been >> more Unicode

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-11-03 Thread Peter Geoghegan
Andres Freund wrote: Here's that patch. I've stared at this some, and Robert did too. Robert mentioned that the commit message might need some polish and I'm not 100% sure about the error message texts yet. The commit message should probably say that the bug involves the

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-03 Thread Tom Lane
Claudio Freire writes: > On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote: >> BTW, the originally given test case shows no measurable improvement >> on my box. > I did manage to reproduce the original test and got a consistent improvement. It occurred

Re: [HACKERS] Proposal: Local indexes for partitioned table

2017-11-03 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> It might work to build the new key in a context that's initially a >> child of CurrentMemoryContext, then reparent it to be a child of >> CacheMemoryContext when done. > That's another way (than the PG_TRY block), but I think

Re: [HACKERS] ucs_wcwidth vintage

2017-11-03 Thread Alvaro Herrera
Thomas Munro wrote: > Hi hackers, > > src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth > implementation that originally arrived in commit df4cba68, but the > upstream code[1] apparently continued evolving and there have been > more Unicode revisions since. It probably doesn't matter

Re: [HACKERS] ucs_wcwidth vintage

2017-11-03 Thread Alvaro Herrera
Thomas Munro wrote: > Hi hackers, > > src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth > implementation that originally arrived in commit df4cba68, but the > upstream code[1] apparently continued evolving and there have been > more Unicode revisions since. I think we should update it

Re: [HACKERS] Proposal: Local indexes for partitioned table

2017-11-03 Thread Alvaro Herrera
> Robert Haas writes: > > We could do that, but the motivation for the current system was to > > avoid leaking memory in a long-lived context. Yeah, my approach here is to use a CATCH block that deletes the memory context just created, thus avoiding a long-lived leak.

Re: [HACKERS] Where is it documented what role executes constraint triggers?

2017-11-03 Thread Tom Lane
Chapman Flack writes: > From a little experimenting in 9.5, it seems that a referential > integrity trigger is executed with the identity of the referencED > table's owner, but I have not been able to find this covered in > the docs. Is this a documentation oversight, or is

Re: [HACKERS] Where is it documented what role executes constraint triggers?

2017-11-03 Thread Nico Williams
On Fri, Nov 03, 2017 at 02:09:00PM -0400, Chapman Flack wrote: > From a little experimenting in 9.5, it seems that a referential > integrity trigger is executed with the identity of the referencED > table's owner, but I have not been able to find this covered in > the docs. Is this a documentation

[HACKERS] Where is it documented what role executes constraint triggers?

2017-11-03 Thread Chapman Flack
>From a little experimenting in 9.5, it seems that a referential integrity trigger is executed with the identity of the referencED table's owner, but I have not been able to find this covered in the docs. Is this a documentation oversight, or is it explained somewhere I didn't look (or may have

Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints

2017-11-03 Thread Nico Williams
On Fri, Nov 03, 2017 at 01:41:45PM -0400, Peter Eisentraut wrote: > On 11/2/17 16:54, Nico Williams wrote: > > Replacing condeferred and condeferrable with a char columns also > > occurred to me, and though I assume backwards-incompatible changes to > > pg_catalog tables are fair game, I assumed

Re: [HACKERS] Dynamic result sets from procedures

2017-11-03 Thread Peter Eisentraut
On 11/2/17 16:40, Daniel Verite wrote: > But instead of having procedures not return anything, > couldn't they return whatever resultset(s) they want to > ("no resultset" being just a particular case of "anything"), > so that we could leave out cursors and simply write: We could in general design

Re: [HACKERS] Add some const decorations to prototypes

2017-11-03 Thread Tom Lane
Peter Eisentraut writes: > On 10/31/17 10:56, Tom Lane wrote: >>> Some functions have a strtol()-like behavior >>> where they take in a const char * and return a pointer into that as >>> another argument. In those cases, I added a cast or two. >> ... but I'm

Re: [HACKERS] Dynamic result sets from procedures

2017-11-03 Thread Peter Eisentraut
On 11/1/17 22:40, Robert Haas wrote: > That seems like it is at least arguably a wire protocol break. Today, > if you send a string containing only one command, you will only get > one answer. The wire protocol already supports this. And the wire protocol doesn't really know about statements,

Re: [HACKERS] Dynamic result sets from procedures

2017-11-03 Thread Peter Eisentraut
On 11/1/17 06:23, Pavel Stehule wrote: > We need to think about how the \timing option should work in such > scenarios.  Right now it does > Has the total time sense  in this case? > > should not be total time related to any fetched result? The \timing option in psql measures from the

Re: [HACKERS] Linking libpq statically to libssl

2017-11-03 Thread Peter Eisentraut
On 11/2/17 19:52, Stephen Frost wrote: > Uh, libpq doesn't actually have symbol versioning, at least not on the > installed Ubuntu packages for PG10, as shown by objdump -T : You're right, I was dreaming. But in any case, he would need symbol versioning of libssl. -- Peter Eisentraut

Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints

2017-11-03 Thread Peter Eisentraut
On 11/2/17 16:54, Nico Williams wrote: > Replacing condeferred and condeferrable with a char columns also > occurred to me, and though I assume backwards-incompatible changes to > pg_catalog tables are fair game, I assumed everyone would prefer > avoiding such changes where possible. I don't

Re: [HACKERS] Add some const decorations to prototypes

2017-11-03 Thread Peter Eisentraut
On 10/31/17 10:56, Tom Lane wrote: >> Some functions have a strtol()-like behavior >> where they take in a const char * and return a pointer into that as >> another argument. In those cases, I added a cast or two. > ... but I'm not sure that it's an improvement in cases where you have to > cast

Re: [HACKERS] MERGE SQL Statement for PG11

2017-11-03 Thread Peter Geoghegan
Simon Riggs wrote: The *only* behavioural difference I have proposed would be the *lack* of an ERROR in (some) concurrent cases. I think that's a big difference. Error vs. non-error is a big deal by itself; Are you saying avoiding an ERROR is a bad or good thing?

Re: [HACKERS] Subscriber resets additional columns to NULL on UPDATE

2017-11-03 Thread Peter Eisentraut
On 10/26/17 05:20, Petr Jelinek wrote: > I found bug in logical replication where extra (nullable) columns on > subscriber will be reset to NULL value when update comes from provider. > > The issue is apparently that we /points finger at himself/ forgot to > check specifically for columns that

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Do we still need the complication in brinsummarize to discriminate > >> against the last partial range? Now that the lock consideration > >> is gone, I think that might be a wart. > > > In the case of

Re: [HACKERS] Exclude pg_internal.init from base backup

2017-11-03 Thread Petr Jelinek
Hi, On 02/09/17 21:08, David Steele wrote: > Hackers, > > The cache in pg_internal.init was reused in days of yore but has been > rebuilt on postmaster startup since v8.1. It appears there is no reason > for this file to be backed up. > Makes sense. > I also moved the RELCACHE_INIT_FILENAME

Re: [HACKERS] Skip unneeded temp file in 'make html'

2017-11-03 Thread David Fetter
On Fri, Nov 03, 2017 at 11:34:18AM -0400, Peter Eisentraut wrote: > On 11/2/17 22:07, David Fetter wrote: > > postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML) > > - $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp > > - $(call mangle-xml,book) > > + $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x

Re: [HACKERS] Skip unneeded temp file in 'make html'

2017-11-03 Thread Peter Eisentraut
On 11/2/17 22:07, David Fetter wrote: > postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML) > - $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp > - $(call mangle-xml,book) > + $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< | $(call mangle-xml,book) The reason why it's not done that

Re: [HACKERS] WIP: Aggregation push-down

2017-11-03 Thread Antonin Houska
Antonin Houska wrote: > This is another version of the patch. > shard.tgz demonstrates the typical postgres_fdw use case. One query shows base > scans of base relation's partitions being pushed to shard nodes, the other > pushes down a join and performs aggregation of the join

Re: [HACKERS] Walsender timeouts and large transactions

2017-11-03 Thread Petr Jelinek
Hi, thanks for checking. On 02/11/17 10:00, Robert Haas wrote: > On Wed, Nov 1, 2017 at 8:19 PM, Petr Jelinek > wrote: >> sorry for the delay but I didn't have much time in past weeks to follow >> this thread. > > +TimestampTz now = GetCurrentTimestamp(); > +

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-11-03 Thread Andres Freund
On 2017-11-02 06:05:51 -0700, Andres Freund wrote: > Hi, > > On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote: > > Andres Freund wrote: > > > I think the problem is on the pruning, rather than the freezing side. We > > > can't freeze a tuple if it has an alive predecessor - rather than > > >

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-03 Thread Claudio Freire
On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote: > Sokolov Yura writes: >> [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ] > > I started to review this patch. I spent a fair amount of time on > beautifying the code, because I found it

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> Do we still need the complication in brinsummarize to discriminate >> against the last partial range? Now that the lock consideration >> is gone, I think that might be a wart. > In the case of VACUUM, it's not desirable to

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > > Yeah, I think this approach results in better code. The attached patch > > implements that, and it passes the test for me (incl. calling > > brin_summarize_new_values concurrently with vacuum, when running the > > insert;

Re: [HACKERS] MERGE SQL Statement for PG11

2017-11-03 Thread Simon Riggs
On 3 November 2017 at 08:26, Robert Haas wrote: > On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote: >>> Therefore, if MERGE eventually uses INSERT .. ON CONFLICT >>> UPDATE when a relevant unique index exists and does something else, >>> such as

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Tom Lane
Alvaro Herrera writes: > Alvaro Herrera wrote: >> Maybe a solution is to call RelationGetNumberOfBlocks() after the >> placeholder tuple has been inserted, for the case where we would be >> scanning past end of relation; passing InvalidBlockNumber as stop point >> would

Re: [HACKERS] [PATCH] A hook for session start

2017-11-03 Thread Fabrízio de Royes Mello
On Fri, Nov 3, 2017 at 11:43 AM, Aleksandr Parfenov < a.parfe...@postgrespro.ru> wrote: > > README file in patch 0003 is a copy of README from test_pg_dump module > without any changes. > Thanks, I'll fix it. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira:

Re: [HACKERS] [PATCH] A hook for session start

2017-11-03 Thread Fabrízio de Royes Mello
On Fri, Nov 3, 2017 at 11:19 AM, Michael Paquier wrote: > > /* > + * Setup handler to session end hook > + */ > +if (IsUnderPostmaster) > +on_proc_exit(do_session_end_hook, 0); > I think that it would be better to place that in ShutdownPostgres.

Re: [HACKERS] [PATCH] A hook for session start

2017-11-03 Thread Aleksandr Parfenov
README file in patch 0003 is a copy of README from test_pg_dump module without any changes. -- Aleksandr Parfenov Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [PATCH] A hook for session start

2017-11-03 Thread Michael Paquier
On Thu, Nov 2, 2017 at 11:36 PM, Fabrízio de Royes Mello wrote: > On Thu, Nov 2, 2017 at 5:42 AM, Aleksandr Parfenov > wrote: >> Unfortunately, patches 0001 and 0002 don't apply to current master. >> >> The new status of this patch is: Waiting

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

2017-11-03 Thread Alvaro Herrera
Alvaro Herrera wrote: > Maybe a solution is to call RelationGetNumberOfBlocks() after the > placeholder tuple has been inserted, for the case where we would be > scanning past end of relation; passing InvalidBlockNumber as stop point > would indicate to do things that way. I'll try with that

[HACKERS] LDAPS

2017-11-03 Thread Thomas Munro
Hi hackers, I've run into a few requests for $SUBJECT in the field. I understand that this is a bit controversial: LDAP + StartTLS (what we already support) is better than LDAPS because it's a proper standard, and LDAP auth in general is not as good as some other authentication methods that we

Re: [HACKERS] parallelize queries containing initplans

2017-11-03 Thread Amit Kapila
On Mon, Oct 30, 2017 at 10:07 AM, Robert Haas wrote: > On Mon, Oct 30, 2017 at 9:00 AM, Amit Kapila wrote: >> Now that the PARAM_EXTERN issue is fixed, I have rebased this patch. >> This patch had been switched to Ready For Committer in last CF,

[HACKERS] LDAP URI decoding bugs

2017-11-03 Thread Thomas Munro
Hi hackers, 1. If you set up a pg_hba.conf with a URL that lacks a base DN or hostname, hba.c will segfault on startup when it tries to pstrdup a null pointer. Examples: ldapurl="ldap://localhost; and ldapurl="ldap://;. 2. If we fail to bind but have no binddn configured, we'll pass NULL to

Re: [HACKERS] proposal: schema variables

2017-11-03 Thread Chris Travers
Some thoughts on this. On Thu, Nov 2, 2017 at 4:48 PM, Tom Lane wrote: > Nico Williams writes: > > With access controls, GUCs could become schema variables, and settings > > from postgresql.conf could move into the database itself (which I think > >

Re: [HACKERS] dropping partitioned tables without CASCADE

2017-11-03 Thread Alvaro Herrera
Ashutosh Bapat wrote: > On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera > wrote: > > I think adding "is partitioned" at end of line isn't good; looks like a > > phrase but isn't translatable. Maybe add keyword PARTITIONED instead? > > In that case may be we should

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-03 Thread Michael Paquier
On Fri, Nov 3, 2017 at 12:07 PM, Michael Paquier wrote: > The patch sent previously does not directly apply on HEAD, and as far > as I can see the last patch set published on > https://www.postgresql.org/message-id/2361ae4a-66b1-c6c5-ea6a-84851a1c0...@postgrespro.ru >

Re: [HACKERS] Is it time to kill support for very old servers?

2017-11-03 Thread Michael Paquier
On Mon, Oct 16, 2017 at 10:08 PM, Andres Freund wrote: > On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote: >> On 9/20/17 04:32, Andres Freund wrote: >> > Here's what I roughly was thinking of. I don't quite like the name, and >> > the way the version is specified for

Re: [HACKERS] dropping partitioned tables without CASCADE

2017-11-03 Thread Ashutosh Bapat
On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2017/09/06 19:14, Amit Langote wrote: >> > On 2017/09/06 18:46, Rushabh Lathia wrote: >> >> Okay, I have marked this as ready for committer. >> > >> > Thanks Ashutosh and Rushabh for

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-03 Thread Michael Paquier
On Fri, Nov 3, 2017 at 11:29 AM, Nikita Glukhov wrote: > By standard only string literals can be used in JSON path specifications. > But of course it is possible to allow to use variable jsonpath expressions > in > SQL/JSON functions. > > Attached patch implements this

Re: [HACKERS] postgres_fdw: Add support for INSERT OVERRIDING clause

2017-11-03 Thread Michael Paquier
On Tue, Oct 31, 2017 at 3:45 PM, Peter Eisentraut wrote: > It has been pointed out to me that the command deparsing in postgres_fdw > does not support the INSERT OVERRIDING clause that was added in PG10. > Here is a patch that seems to fix that. I don't know

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-03 Thread Nikita Glukhov
On 03.11.2017 00:32, Piotr Stefaniak wrote: On 2017-02-28 20:08, Oleg Bartunov wrote: The standard describes SQL/JSON path language, which used by SQL/JSON query operators to query JSON. It defines path language as string literal. We implemented the path language as JSONPATH data type, since

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM