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
>>
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
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
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
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.
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
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
--
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
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
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
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
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
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
13 matches
Mail list logo