Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

2018-02-03 Thread Amit Kapila
On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote: > On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila wrote: > [] >> I think you can manually (via debugger) hit this by using >> PUBLICATION/SUBSCRIPTION syntax for logical replication. I think what >>

Re: JIT compiling with LLVM v9.1

2018-02-03 Thread Andreas Karlsson
On 02/02/2018 10:48 AM, Pierre Ducroquet wrote: I have successfully built the JIT branch against LLVM 4.0.1 on Debian testing. This is not enough for Debian stable (LLVM 3.9 is the latest available there), but it's a first step. I've split the patch in four files. The first three fix the build

Re: [HACKERS] MERGE SQL Statement for PG11

2018-02-03 Thread Peter Geoghegan
On Sat, Feb 3, 2018 at 2:15 PM, Simon Riggs wrote: >> I started looking at SQL Server's MERGE to verify that it also does >> not impose any restrictions on subselects in a MERGE UPDATE's >> targetlist, just like Oracle. Unsurprisingly, it does not. More >> surprisingly, I

Re: [HACKERS] MERGE SQL Statement for PG11

2018-02-03 Thread Simon Riggs
On 1 February 2018 at 19:39, Peter Geoghegan wrote: > Finally, I noticed a problem with your new EXPLAIN ANALYZE instrumentation: > > Is it 4 rows inserted, or 0 inserted? > > postgres=# merge into testoids a using (select i "key", 'foo' "data" > from generate_series(0,3) i) b on

Re: [HACKERS] MERGE SQL Statement for PG11

2018-02-03 Thread Simon Riggs
On 3 February 2018 at 19:57, Andreas Seltenreich wrote: > as promised in Brussels, I taught sqlsmith about MERGE and did some > testing with merge.v14.patch applied on master at 9aef173163. > > So far, it found a couple of failing assertions and a suspicous error > message.

Re: [HACKERS] MERGE SQL Statement for PG11

2018-02-03 Thread Simon Riggs
On 2 February 2018 at 01:59, Peter Geoghegan wrote: > On Thu, Feb 1, 2018 at 11:39 AM, Peter Geoghegan wrote: >> There is also the matter of subselects in the update targetlist, which >> you similarly claim is only a problem of having the wrong error >> message. The

Re: [HACKERS] MERGE SQL Statement for PG11

2018-02-03 Thread Andreas Seltenreich
Hi, as promised in Brussels, I taught sqlsmith about MERGE and did some testing with merge.v14.patch applied on master at 9aef173163. So far, it found a couple of failing assertions and a suspicous error message. Details and Testcases against the regression database below. regards, Andreas --

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

2018-02-03 Thread Mark Rofail
On Sat, 3 Feb 2018 at 5:14 pm, Andreas Karlsson wrote: > If I am right my recommendation for getting this patch in is to > initially skip the new operators and go back to the version of the patch > which uses @>. We really need an initial patch to get accepted and postpone

Re: pie-in-sky idea: 'sensitive' function parameters

2018-02-03 Thread Chapman Flack
On 02/02/18 22:46, Tom Lane wrote: > ... the problem with this idea is that knowledge that the item ought to be > hidden would be obtained only very late in the parsing process. So for > example if you fat-fingered something just to the left of the function > call in the query text, or the name

Re: Regexp named capture groups

2018-02-03 Thread Michael Paquier
On Sat, Feb 03, 2018 at 01:55:31PM +0100, Pavel Stehule wrote: > 2018-02-03 11:19 GMT+01:00 Joel Jacobson : >> Is anyone working on this feature[1] also for PostgreSQL's regex >> engine? Note that I know of. >> I think this feature would be awesome, for the reasons mentioned in

Regexp named capture groups

2018-02-03 Thread Joel Jacobson
Hi hackers, Is anyone working on this feature[1] also for PostgreSQL's regex engine? I'm thinking it could work something like this: joel=# \df regexp_match List of functions Schema | Name | Result data type | Argument data types | Type

Re: JIT compiling with LLVM v9.1

2018-02-03 Thread Andres Freund
Hi, On 2018-02-03 01:13:21 -0800, Andres Freund wrote: > On 2018-02-02 18:21:12 -0800, Jeff Davis wrote: > > I think I saw about a 2% gain here over master, but when I applied it > > on top of the fast scans it did not seem to add anything on top of > > fast scans. Seems reproducible, but I don't

Re: JIT compiling with LLVM v9.1

2018-02-03 Thread Andres Freund
Hi, On 2018-02-02 18:21:12 -0800, Jeff Davis wrote: > On Mon, Jan 29, 2018 at 1:53 AM, Andres Freund wrote: > >> https://git.postgresql.org/git/users/andresfreund/postgres.git > > There's a patch in there to change the scan order. Yes - note it's "deactivated" at the