Re: [HACKERS] [v9.5] Custom Plan API

> FYI, patch v12 part 2 no longer applies cleanly. > Thanks. I rebased the patch set according to the latest master branch. The attached v13 can be applied to the master. -- NEC OSS Promotion Center / PG-Strom Project KaiGai Kohei > -Original Message- > From: thombr...@gmail.com [mailto:

Re: [HACKERS] CINE in CREATE TABLE AS ... and CREATE MATERIALIZED VIEW ...

Hi All, - Patch got applied cleanly. - Regression make check run fine. - Patch covered the documentation changes Here are few comments: 1) What the need of following change: diff --git a/src/backend/storage/lmgr/lwlock.c b/src/backend/storage/lmgr/lwlock.c index bcec173..9fe6855 100644 --- a/sr

Re: [HACKERS] alter user/role CURRENT_USER

Thanks Kyotaro, I just did quickly looked at the patch and it does cover more syntax then earlier patch. But still if doesn't not cover the all the part of syntax where we can use CURRENT_USER/CURRENT_ROLE/USER/SESSION_USER. For example: -- Not working alter default privileges for role current_us

Re: [HACKERS] [BUGS] ltree::text not immutable?

On 10/26/14, 3:46 PM, Tom Lane wrote: I wrote: More generally, it seems like we ought to have a test in the type_sanity regression script that checks that type I/O functions aren't volatile, ... Actually, the right thing to do if we want to enforce this is for CREATE TYPE to check the marking

Re: [HACKERS] Function array_agg(array)

2014-10-27 1:38 GMT+07:00 Pavel Stehule : > Hi > > My idea is using new ArrayBuilder optimized for building multidimensional > arrays with own State type. I think so casting to ArrayBuildState is base > of our problems, so I don't would to do. Code in array_agg_* is simple, > little bit more compl

Re: [HACKERS] Reducing lock strength of adding foreign keys

On 10/24/2014 06:07 PM, Robert Haas wrote: I think instead of focusing on foreign keys, we should rewind a bit and think about the locking level required to add a trigger. Agreed. As far as triggers are concerned, the issue of skew between the transaction snapshot and what the ruleutils.c sna

Re: [HACKERS] pset_quoted_string is broken

On Mon, Oct 27, 2014 at 12:20 PM, Tom Lane wrote: > David Rowley writes: > > It seems the buffer created in pset_quoted_string is just 1 char too > small. > > Yeah, that's a bug. Fix pushed, thanks! > > Thanks for committing. > > This breaks psql's \pset for me, though I've no idea why the bu

Re: [HACKERS] [PATCH] Simplify EXISTS subqueries containing LIMIT

On Mon, Oct 27, 2014 at 1:56 AM, Marti Raudsepp wrote: > On Wed, Oct 22, 2014 at 1:37 PM, David Rowley > wrote: > > I've had a bit of a look at this and here's a couple of things: > > Thanks. Sorry I didn't back to you earlier, I almost forgot about the > review. > > > /* > > +*

Re: [HACKERS] pg_dump/pg_restore seem broken on hamerkop

I wrote: > Hm. %z ought not be locale-dependent ... however, it has a bigger > problem, which is that it's a C99-ism. It's not there in SUSv2, > which is our normal baseline for what's portable. I think we need > to get rid of that. %Z should be portable. > (Is it possible that Windows' strfti

Re: [HACKERS] pg_dump/pg_restore seem broken on hamerkop

Alvaro Herrera writes: > So this seems related to the %z part of the strftime() call. I have no > explanation for this failure ATM; maybe pg_restore is failing to set the > locale properly? I also notice pg_restore.c previously included > pg_backup_archiver.h (which in turn includes ); strftime

Re: [HACKERS] pg_dump/pg_restore seem broken on hamerkop

Tatsuo Ishii wrote: > > Buildfarm member hamerkop has been failing in the pg_upgrade regression > > test for the last several days. The problem looks like this: > > > > command: > > "C:/buildfarm/build_root/HEAD/pgsql.build/contrib/pg_upgrade/tmp_check/install/bin/pg_restore" > > --port 50432 -

Re: [HACKERS] pset_quoted_string is broken

David Rowley writes: > It seems the buffer created in pset_quoted_string is just 1 char too small. Yeah, that's a bug. Fix pushed, thanks! > This breaks psql's \pset for me, though I've no idea why the buildfarm is > not complaining a bit more. I think in most cases, maxalign padding of the ma

Re: [HACKERS] pg_dump/pg_restore seem broken on hamerkop

>> Buildfarm member hamerkop has been failing in the pg_upgrade regression >> test for the last several days. The problem looks like this: >> >> command: >> "C:/buildfarm/build_root/HEAD/pgsql.build/contrib/pg_upgrade/tmp_check/install/bin/pg_restore" >> --port 50432 --username "Administrator"

Re: [HACKERS] narwhal and PGDLLIMPORT

Noah Misch writes: > Calls to ldap_init() exhibit the same problem shfolder.dll:SHGetFolderPath() > exhibited: it loads and unloads some DLLs, and it manages to unload libpq in > passing. There's nothing comparable to the above workaround this time, but I > found a more fundamental fix. > ... > l

[HACKERS] pset_quoted_string is broken

It seems the buffer created in pset_quoted_string is just 1 char too small. This breaks psql's \pset for me, though I've no idea why the buildfarm is not complaining a bit more. As it stands, if the function is given an empty string to quote, it tries to build a string with 2 single quotes and a

Re: [HACKERS] narwhal and PGDLLIMPORT

On Wed, Oct 22, 2014 at 12:12:36AM -0400, Noah Misch wrote: > On Mon, Oct 20, 2014 at 01:03:31AM -0400, Noah Misch wrote: > > I reproduced narwhal's problem using its toolchain on another 32-bit Windows > > Server 2003 system. The crash happens at the SHGetFolderPath() call in > > pqGetHomeDirecto

[HACKERS] proposal: CREATE DATABASE vs. (partial) CHECKPOINT

Hi all, currently, CREATE DATABASE forces an immediate checkpoint (actually, it forces two, but the time interval is usually rather small). For traditional deployments this is not a big deal, because creating a database is a rare event, and may be planned to off-peak times. However for shared (cl

Re: [HACKERS] strip nulls functions for json and jsonb

On 10/26/2014 04:22 PM, Pavel Stehule wrote: 2014-10-26 21:18 GMT+01:00 Andrew Dunstan >: On 10/26/2014 04:14 PM, Thom Brown wrote: On 26 October 2014 20:07, Andrew Dunstan mailto:and...@dunslane.net>

Re: [HACKERS] [BUGS] ltree::text not immutable?

I wrote: >> More generally, it seems like we ought to have a test in the type_sanity >> regression script that checks that type I/O functions aren't volatile, >> ... > Actually, the right thing to do if we want to enforce this is for > CREATE TYPE to check the marking. We'd still need a type_sani

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Sat, Oct 25, 2014 at 8:12 AM, Robert Haas wrote: >> Generating index paths for the UPDATE is a waste of cycles. >> Theoretically, there could be an (a, b, c) unique index and a (c,b,a) >> unique index, and those two might have a non-equal cost to scan. But >> that almost certainly isn't going t

Re: [HACKERS] TAP test breakage on MacOS X

Andrew Dunstan writes: > On 10/26/2014 12:29 PM, Tom Lane wrote: >> The pathname length problem I noted in >> http://www.postgresql.org/message-id/16477.1413831...@sss.pgh.pa.us >> seems like a show-stopper as well, since undoubtedly a number of >> buildfarm critters are using buildroots with path

Re: [HACKERS] strip nulls functions for json and jsonb

On 10/26/2014 04:14 PM, Thom Brown wrote: On 26 October 2014 20:07, Andrew Dunstan > wrote: On 10/26/2014 03:50 PM, Pavel Stehule wrote: Hi I have a question, what is expected result of null strip of {"a": {"b": null, "c", nul

Re: [HACKERS] strip nulls functions for json and jsonb

2014-10-26 21:18 GMT+01:00 Andrew Dunstan : > > On 10/26/2014 04:14 PM, Thom Brown wrote: > >> On 26 October 2014 20:07, Andrew Dunstan > and...@dunslane.net>> wrote: >> >> >> On 10/26/2014 03:50 PM, Pavel Stehule wrote: >> >> Hi >> >> I have a question, >> >> what is e

Re: [HACKERS] Performance regression: 9.2+ vs. ScalarArrayOpExpr vs. ORDER BY

I wrote: > Andrew Gierth writes: >> "Bruce" == Bruce Momjian writes: >> Bruce> Uh, did this ever get addressed? >> It did not. > It dropped off the radar screen (I think I'd assumed the patch would > appear in the next commitfest, which it didn't unless I missed something). > I'll make a note t

Re: [HACKERS] strip nulls functions for json and jsonb

On 26 October 2014 20:07, Andrew Dunstan wrote: > > On 10/26/2014 03:50 PM, Pavel Stehule wrote: > >> Hi >> >> I have a question, >> >> what is expected result of null strip of >> >> {"a": {"b": null, "c", null"} } >> >> ? >> >> > > Please remember not to top-post. > > The above is not legal json

Re: [HACKERS] strip nulls functions for json and jsonb

On 10/26/2014 03:50 PM, Pavel Stehule wrote: Hi I have a question, what is expected result of null strip of {"a": {"b": null, "c", null"} } ? Please remember not to top-post. The above is not legal json, so the answer would be an error. cheers andrew -- Sent via pgsql-hackers mailin

Re: [HACKERS] strip nulls functions for json and jsonb

Hi I have a question, what is expected result of null strip of {"a": {"b": null, "c", null"} } ? 2014-10-26 19:59 GMT+01:00 Andrew Dunstan : > > On 10/16/2014 04:12 PM, Pavel Stehule wrote: > >> >> >> 1. missing documentation >> >> 2. I miss more comments related to this functions. This code

Re: [HACKERS] strip nulls functions for json and jsonb

On 10/16/2014 04:12 PM, Pavel Stehule wrote: 1. missing documentation 2. I miss more comments related to this functions. This code is relative simple, but some more explanation can be welcome. 3. why these functions are marked as "stable"? New patch: Docs added, functions marked immut

Re: [HACKERS] TAP test breakage on MacOS X

On 10/26/2014 12:29 PM, Tom Lane wrote: Andrew Dunstan writes: On 10/07/2014 01:57 PM, Tom Lane wrote: Peter had a patch to eliminate the overhead of multiple subinstalls; not sure where that stands, but presumably it would address your issue. Is there any progress on this. I'm reluctant to

Re: [HACKERS] Function array_agg(array)

Hi My idea is using new ArrayBuilder optimized for building multidimensional arrays with own State type. I think so casting to ArrayBuildState is base of our problems, so I don't would to do. Code in array_agg_* is simple, little bit more complex code is in nodeSubplan.c. Some schematic changes ar

Re: [HACKERS] TAP test breakage on MacOS X

Andrew Dunstan writes: > On 10/07/2014 01:57 PM, Tom Lane wrote: >> Peter had a patch to eliminate the overhead of multiple subinstalls; >> not sure where that stands, but presumably it would address your issue. > Is there any progress on this. I'm reluctant to add this to the > buildfarm client

Re: [HACKERS] TAP test breakage on MacOS X

On 10/07/2014 01:57 PM, Tom Lane wrote: Andrew Dunstan writes: I don't much like the idea of doing an install/initdb/start for every directory in src/bin, though. Can't we at least manage a single installation directory for all these? Peter had a patch to eliminate the overhead of multiple su

Re: [HACKERS] TAP test breakage on MacOS X

On 10/9/14 3:38 PM, Robert Haas wrote: > The problem is that running initdb --not-a-valid-option leaves $? set > to 256, as seems entirely unsurprising. After running the anonymous > block passed to it, Test::Builder::subtest calls Test::Build::finalize > which calls Test::Build::_ending, which se

Re: [HACKERS] [PATCH] Simplify EXISTS subqueries containing LIMIT

On Wed, Oct 22, 2014 at 1:37 PM, David Rowley wrote: > I've had a bit of a look at this and here's a couple of things: Thanks. Sorry I didn't back to you earlier, I almost forgot about the review. > /* > +* LIMIT clause can be removed if it's a positive constant or ALL, to > +

Re: [HACKERS] [v9.5] Custom Plan API

On 30 September 2014 07:27, Kouhei Kaigai wrote: > > On Mon, Sep 29, 2014 at 9:04 AM, Kohei KaiGai > wrote: > > > Do we need to match the prototype of wrapper function with callback? > > > > Yes. > > > OK, I fixed up the patch part-2, to fit declaration of > GetSpecialCustomVar() > with correspo