Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

2015-09-11 Thread Andrew Dunstan
On 09/09/2015 01:03 PM, Oskari Saarenmaa wrote: 09.09.2015, 18:53, Andrew Dunstan kirjoitti: On 09/08/2015 09:54 AM, Andrew Dunstan wrote: On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote: There was a long thread about concatenating jsonb objects to each other, but that discussion didn&#

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

2015-09-09 Thread Andrew Dunstan
On 09/08/2015 09:54 AM, Andrew Dunstan wrote: On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote: There was a long thread about concatenating jsonb objects to each other, but that discussion didn't touch concatenating other types. Currently jsonb_concat always just returns the other arg

Re: [HACKERS] Counting lines correctly in psql help displays

2015-09-09 Thread Andrew Dunstan
On 09/09/2015 10:27 AM, Tom Lane wrote: Andrew Dunstan writes: On 09/05/2015 12:55 PM, Tom Lane wrote: Or we could just give up and replace the counts by INT_MAX, forcing use of the pager unless you've turned it off. All of those outputs are long enough now that it's hard to bel

Re: [HACKERS] Counting lines correctly in psql help displays

2015-09-08 Thread Andrew Dunstan
On 09/05/2015 12:55 PM, Tom Lane wrote: I wrote: BTW, I noticed that the PageOutput line counts for psql's usage(), slashUsage(), and helpVariables() were all three wrong, which I'm afraid has been their usual state in the past too. Since commit 07c8651dd91d5aea there's been a pretty easy way

Re: [HACKERS] pgsql: Improve logging of TAP tests.

2015-09-08 Thread Andrew Dunstan
On 09/08/2015 02:58 PM, Stephen Frost wrote: * Andrew Dunstan (and...@dunslane.net) wrote: Improve logging of TAP tests. [...] This broke 'make check' for REL9_4_STABLE with --enable-tap-tests because it added a reference to 'with_temp_install' but didn't actually

Re: [HACKERS] exposing pg_controldata and pg_config as functions

2015-09-08 Thread Andrew Dunstan
On 09/08/2015 04:21 PM, Peter Eisentraut wrote: On 9/7/15 7:32 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: I already gave a use case that you dismissed in favour of a vague solution that we don't actually have. You seem to be the only person objecting to this proposal. I think tha

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

2015-09-08 Thread Andrew Dunstan
On 09/08/2015 10:48 AM, Teodor Sigaev wrote: This looks correct. Barring objection I'll apply this shortly. +1 Seems correct. Should we backpatch that? Yes, certainly. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscripti

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

2015-09-08 Thread Andrew Dunstan
On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote: There was a long thread about concatenating jsonb objects to each other, but that discussion didn't touch concatenating other types. Currently jsonb_concat always just returns the other argument if one of arguments is considered empty. This cau

Re: [HACKERS] exposing pg_controldata and pg_config as functions

2015-09-07 Thread Andrew Dunstan
On 09/06/2015 11:17 PM, Peter Eisentraut wrote: On 9/6/15 3:34 PM, Joe Conway wrote: On 09/02/2015 02:54 PM, Alvaro Herrera wrote: Josh Berkus wrote: On 09/02/2015 02:34 PM, Alvaro Herrera wrote: I think trying to duplicate the exact strings isn't too nice an interface. Well, for pg_contro

Re: [HACKERS] Creating unique or "internal-use-only" column names (ColumnRef)

2015-09-07 Thread Andrew Dunstan
On 09/07/2015 09:28 AM, Alvaro Herrera wrote: Peter Moser wrote: Good afternoon, is it possible to create unique column names or to give column names inside the parser phase that do not interfer with the outside world, i.e. with column names from tables or aliases given by the user. Some shor

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

2015-09-03 Thread Andrew Dunstan
On 09/03/2015 03:31 PM, Tom Lane wrote: I wrote: Andres Freund writes: I'don't like adding a couple seconds of test runtime for the benefit of very slow platforms. Me either. This is the first time I've seen an indication that the start_postmaster change mentioned in the comment is actuall

Re: [HACKERS] src/test/ssl broken on HEAD

2015-09-02 Thread Andrew Dunstan
On 09/02/2015 04:22 PM, Robert Haas wrote: On Wed, Aug 26, 2015 at 3:37 AM, Michael Paquier wrote: On Wed, Aug 26, 2015 at 4:35 PM, Michael Paquier wrote: Only HEAD is impacted, and attached is a patch to fix the problem. Actually this version is better, I forgot to update a comment. For

Re: [HACKERS] perlcritic

2015-09-01 Thread Andrew Dunstan
On 08/31/2015 11:57 PM, Peter Eisentraut wrote: We now have 80+ Perl files in our tree, and it's growing. Some of those files were originally written for Perl 4, and the coding styles and quality are quite, uh, divergent. So I figured it's time to clean up that code a bit. I ran perlcritic o

Re: [HACKERS] pg_upgrade + Extensions

2015-08-31 Thread Andrew Dunstan
On 08/31/2015 07:32 PM, Bruce Momjian wrote: On Mon, Aug 31, 2015 at 07:28:00PM -0400, Andrew Dunstan wrote: On 08/31/2015 07:21 PM, David E. Wheeler wrote: On Aug 31, 2015, at 4:20 PM, Bruce Momjian wrote: I think it would help if its noted somewhere in the document as it would have

Re: [HACKERS] pg_upgrade + Extensions

2015-08-31 Thread Andrew Dunstan
On 08/31/2015 07:21 PM, David E. Wheeler wrote: On Aug 31, 2015, at 4:20 PM, Bruce Momjian wrote: I think it would help if its noted somewhere in the document as it would have helped us save some time understanding why it was failing and why it was looking for json_build. The problem is tha

Re: [HACKERS] Is "WIN32" #defined in Cygwin builds?

2015-08-31 Thread Andrew Dunstan
On 08/31/2015 02:21 PM, Tom Lane wrote: I started wondering about $subject because we are fairly schizophrenic about whether we believe this. For example, only a few lines apart in dirmod.c, there are #if defined(WIN32) || defined(__CYGWIN__) #if defined(WIN32) && !defined(__CYGWIN__) Presu

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

2015-08-29 Thread Andrew Dunstan
On 08/29/2015 04:27 PM, Tom Lane wrote: Jim Nasby writes: On 8/29/15 12:29 PM, Pavel Stehule wrote: what is correct from JSON perspective? All fields with NULL ISTM that the whole purpose of to_json is to properly jsonify something, and the proper json form for "undefined" is 'null', is it

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

2015-08-29 Thread Andrew Dunstan
On 08/29/2015 12:02 PM, Pavel Stehule wrote: 2015-08-29 15:43 GMT+02:00 Shulgin, Oleksandr mailto:oleksandr.shul...@zalando.de>>: On Sat, Aug 29, 2015 at 3:39 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: Andrew Dunstan mailto:and...@dunslane.net>> write

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

2015-08-29 Thread Andrew Dunstan
On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: On Sat, Aug 29, 2015 at 8:39 AM, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote: Hi currently JSON support NULL value - but we doesn't convert NULL to JSON correctly postgres=# select to_json(NULL::text) IS NULL; ┌─

Re: [HACKERS] Function accepting array of complex type

2015-08-26 Thread Andrew Dunstan
On 08/25/2015 06:21 PM, Jim Nasby wrote: CREATE FUNCTION magsum( c c[] ) RETURNS float LANGUAGE sql AS $$ SELECT sum(sqrt(c.r^2 + c.i^2)) FROM unnest(c) c $$; SELECT magsum( array[row(2.1, 2.1), row(2.2,2.2)] ); SELECT magsum( array[row(2.1, 2.1), row(2.2,2.2)]::c[] ); cheers andrew --

Re: [HACKERS] 9.4 broken on alpha

2015-08-25 Thread Andrew Dunstan
On 08/25/2015 08:30 AM, Andres Freund wrote: On 2015-08-25 08:29:18 -0400, Andrew Dunstan wrote: needs a buildfarm animal. If we had one we'd presumably have caught this much earlier. On the other hand, we dropped alpha support in 9.5, ... Oh, I missed that. Sorry for the noise. c

Re: [HACKERS] 9.4 broken on alpha

2015-08-25 Thread Andrew Dunstan
On 08/25/2015 06:16 AM, Christoph Berg wrote: Hi, >From the Debian ports buildd: https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=alpha&ver=9.4.4-1&stamp=1434132509 make[5]: Entering directory '/«PKGBUILDDIR»/build/src/backend/postmaster' [...] gcc -Wall -Wmissing-prototype

Re: [HACKERS] Declarative partitioning

2015-08-24 Thread Andrew Dunstan
On 08/24/2015 03:46 AM, Simon Riggs wrote: ALTER TABLE foo ADD PARTITION NEXT; when a sequence of partitions has been defined Or perhaps ALTER TABLE foo ADD PARTITION NEXT nn; So you can set up, say, a week's worth of daily partitions at once. I could also imagine a variant that

Re: [HACKERS] psql - better support pipe line

2015-08-24 Thread Andrew Dunstan
On 08/24/2015 06:49 AM, Heikki Linnakangas wrote: On 08/24/2015 08:06 AM, Pavel Stehule wrote: Hi I found so a set "psql" and "xargs" is pretty strong. But I miss a psql option for simple returning current database and continuing in pipeline. What I am doing: psql postgres -At -c "select da

Re: [HACKERS] exposing pg_controldata and pg_config as functions

2015-08-24 Thread Andrew Dunstan
On 08/23/2015 08:58 PM, Michael Paquier wrote: 2) No docs or related regression test yet. I will do that if there is enough interest in this getting committed. So far no one except Andrew and I have chimed in. I think that's a good thing to have, now I have concerns about making this data read

Re: [HACKERS] jsonb array-style subscripting

2015-08-20 Thread Andrew Dunstan
On 08/20/2015 03:24 PM, Jim Nasby wrote: On 8/17/15 4:25 PM, Josh Berkus wrote: On 08/17/2015 02:18 PM, Jim Nasby wrote: >On 8/17/15 3:33 PM, Josh Berkus wrote: >>Again, how do we handle missing keys? Just return NULL? or ERROR? I'd >>prefer the former, but there will be arguments the ot

Re: [HACKERS] TAP tests are badly named

2015-08-20 Thread Andrew Dunstan
On 08/16/2015 08:30 PM, Michael Paquier wrote: On Mon, Aug 17, 2015 at 7:15 AM, Noah Misch wrote: On Sun, Aug 16, 2015 at 05:08:56PM -0400, Andrew Dunstan wrote: On 08/16/2015 02:23 PM, Noah Misch wrote: -sub tapcheck +sub tap_check { - InstallTemp(); + die "Tap tests not enabl

[HACKERS] exposing pg_controldata and pg_config as functions

2015-08-20 Thread Andrew Dunstan
Is there any significant interest in either of these? Josh Berkus tells me that he would like pg_controldata information, and I was a bit interested in pg_config information, for this reason: I had a report of someone who had configured using --with-libxml but the xml tests actually returned t

Re: [HACKERS] jsonb array-style subscripting

2015-08-18 Thread Andrew Dunstan
On 08/18/2015 01:11 AM, Kaare Rasmussen wrote: On 2015-08-17 22:33, Josh Berkus wrote: So, both perl and python do not allow "deep nesting" of assignments. For example: d = { "a" : { } } d["a"]["a1"]["a2"] = 42 Traceback (most recent call last): File "", line 1, in KeyError: 'a1' Not s

Re: [HACKERS] jsonb array-style subscripting

2015-08-18 Thread Andrew Dunstan
On 08/18/2015 01:32 AM, Pavel Stehule wrote: Hi 2015-08-17 21:12 GMT+02:00 Jim Nasby >: On 8/17/15 12:57 PM, Dmitry Dolgov wrote: * is it interesting for the community? We definitely need better ways to manipulate JSON. * is that a

Re: [HACKERS] jsonb array-style subscripting

2015-08-17 Thread Andrew Dunstan
On 08/17/2015 03:26 PM, Merlin Moncure wrote: I'm not sure if this: update test_jsonb_subscript set test_json['a']['a1']['a2'] = 42; ...is a good idea. postgres operators tend to return immutable copies of the item they are referring to. In other words, you'd never see a column operator on t

Re: [HACKERS] More WITH

2015-08-17 Thread Andrew Dunstan
On 08/17/2015 01:30 PM, Peter Geoghegan wrote: On Mon, Aug 17, 2015 at 10:22 AM, Josh Berkus wrote: Would be tricky. We don't currently have any way to wrap an EXPLAIN in any larger statement, do we? Would be very useful for automated query analysis, though. No. In the grammar, ExplainStmt

Re: [HACKERS] what would tar file FDW look like?

2015-08-17 Thread Andrew Dunstan
On 08/17/2015 10:14 AM, Bear Giles wrote: I'm starting to work on a tar FDW as a proxy for a much more specific FDW. (It's the 'faster to build two and toss the first away' approach - tar lets me get the FDW stuff nailed down before attacking the more complex container.) It could also be usef

Re: [HACKERS] TAP tests are badly named

2015-08-16 Thread Andrew Dunstan
On 08/16/2015 02:23 PM, Noah Misch wrote: -sub tapcheck +sub tap_check { - InstallTemp(); + die "Tap tests not enabled in configuration" + unless $config->{tap_tests}; I endorse Heikki's argument for having omitted the configuration flag: http://www.postgresql.org/message

Re: [HACKERS] How to compile, link and use a C++ extension

2015-08-14 Thread Andrew Dunstan
On 08/14/2015 02:10 PM, Peter Geoghegan wrote: On Fri, Aug 14, 2015 at 10:28 AM, Tom Lane wrote: Yeah. The painful issues you're going to face are not that. They are memory management (C++ "new" does not talk to palloc or vice versa) and error handling ("throw" does not interoperate with PG

Re: [HACKERS] Management of simple_eval_estate for plpgsql DO blocks

2015-08-14 Thread Andrew Dunstan
On 08/14/2015 12:42 PM, Tom Lane wrote: In commit 0fc94a5ba I wrote: +* ... It's okay to update the [ session-wide ] +* hash table with the new tree because all plpgsql functions within a +* given transaction share the same simple_eval_estate. Um. Well, that's true for actual fun

Re: [HACKERS] buildfarm does not test "make check"

2015-08-14 Thread Andrew Dunstan
On 08/14/2015 09:27 AM, Robert Haas wrote: On Thu, Aug 13, 2015 at 2:11 PM, Alvaro Herrera wrote: So I added the brin isolation test back. Because it needs the pageinspect module, it can only work under "make check", not installcheck. The problem is that this means buildfarm will not run it

Re: [HACKERS] TAP tests are badly named

2015-08-14 Thread Andrew Dunstan
On 08/14/2015 09:27 AM, Andrew Dunstan wrote: On 08/14/2015 03:32 AM, Noah Misch wrote: On Thu, Aug 13, 2015 at 11:17:40AM -0400, Andrew Dunstan wrote: here's what I propose. This changes more than the tapcheck name and the suites it could run. Would you write up the changes you cho

Re: [HACKERS] TAP tests are badly named

2015-08-14 Thread Andrew Dunstan
On 08/14/2015 03:32 AM, Noah Misch wrote: On Thu, Aug 13, 2015 at 11:17:40AM -0400, Andrew Dunstan wrote: here's what I propose. This changes more than the tapcheck name and the suites it could run. Would you write up the changes you chose to include? That will help guide review.

Re: [HACKERS] [COMMITTERS] pgsql: Re-add BRIN isolation test

2015-08-13 Thread Andrew Dunstan
On 08/13/2015 04:26 PM, Alvaro Herrera wrote: Alvaro Herrera wrote: Re-add BRIN isolation test This time, instead of using a core isolation test, put it on its own test module; this way it can require the pageinspect module to be present before running. The module's Makefile is loosely model

Re: [HACKERS] buildfarm does not test "make check"

2015-08-13 Thread Andrew Dunstan
On 08/13/2015 02:52 PM, Alvaro Herrera wrote: You're also going to have to handle the msvc side of things. That won't be trivial. See discussion elsewhere today about how we've got that wrong recently. Oh my. The pg_upgrade code in src/tools/msvc/vcregress.pl looks rather unhealthy, and I don

Re: [HACKERS] buildfarm does not test "make check"

2015-08-13 Thread Andrew Dunstan
On 08/13/2015 02:11 PM, Alvaro Herrera wrote: So I added the brin isolation test back. Because it needs the pageinspect module, it can only work under "make check", not installcheck. The problem is that this means buildfarm will not run it, because it only runs installcheck :-( I realized th

Re: [HACKERS] TAP tests are badly named

2015-08-13 Thread Andrew Dunstan
On 08/13/2015 12:03 PM, Michael Paquier wrote: On Fri, Aug 14, 2015 at 12:17 AM, Andrew Dunstan wrote: here's what I propose. This patch does not take into account that there may be other code paths than src/bin/ that may have TAP tests (see my pending patch to test pg_dump with exten

Re: [HACKERS] TAP tests are badly named

2015-08-13 Thread Andrew Dunstan
On 08/01/2015 07:13 PM, Andrew Dunstan wrote: On 08/01/2015 04:44 PM, Noah Misch wrote: --enable-tap-tests is a reasonable configuration setting, because it's about whether or not we have a TAP testing framework available, but I think we should stop calling the bin tests "TAP tes

Re: [HACKERS] [COMMITTERS] pgsql: Fix pg_dump to dump shell types.

2015-08-10 Thread Andrew Dunstan
On 08/10/2015 07:29 PM, Tom Lane wrote: I wrote: Peter Eisentraut writes: This was probably just copied from how proacl and lanacl are handled, which predate typacl by quite a bit. Maybe there was a reason in those days. Hm ... I wonder whether those are well-thought-out either. They're n

Re: [HACKERS] tap tests remove working directories

2015-08-10 Thread Andrew Dunstan
On 08/10/2015 10:32 AM, Andrew Dunstan wrote: On 08/10/2015 09:55 AM, Tom Lane wrote: Andrew Dunstan writes: On 08/09/2015 08:58 PM, Michael Paquier wrote: Sure. Attached is what I have in mind. Contrary to your version we keep around temp paths should a run succeed after one that has

Re: [HACKERS] tap tests remove working directories

2015-08-10 Thread Andrew Dunstan
On 08/10/2015 09:55 AM, Tom Lane wrote: Andrew Dunstan writes: On 08/09/2015 08:58 PM, Michael Paquier wrote: Sure. Attached is what I have in mind. Contrary to your version we keep around temp paths should a run succeed after one that has failed when running make check multiple times in a

Re: [HACKERS] tap tests remove working directories

2015-08-10 Thread Andrew Dunstan
On 08/09/2015 08:58 PM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 11:19 PM, Andrew Dunstan wrote: On 08/09/2015 08:41 AM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan wrote: On 08/08/2015 09:31 AM, Robert Haas wrote: On Fri, Aug 7, 2015 at 7:17 PM, Andrew

Re: [HACKERS] tap tests remove working directories

2015-08-09 Thread Andrew Dunstan
On 08/09/2015 08:41 AM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan wrote: On 08/08/2015 09:31 AM, Robert Haas wrote: On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dunstan wrote: That certainly isn't what happens, and given the way this is done in TestLib.pm, usin

Re: [HACKERS] Test code is worth the space

2015-08-08 Thread Andrew Dunstan
On 08/08/2015 05:09 PM, Josh Berkus wrote: On 08/08/2015 12:24 PM, Peter Geoghegan wrote: I think that there needs to be a way of running an extended set of regression tests. I could definitely respect the desire for minimalism when it comes to adding tests to the regression tests proper if the

Re: [HACKERS] tap tests remove working directories

2015-08-08 Thread Andrew Dunstan
On 08/08/2015 09:31 AM, Robert Haas wrote: On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dunstan wrote: That certainly isn't what happens, and given the way this is done in TestLib.pm, using the CLEANUP parameter of File::Temp's tempdir() function, it's not clear how we could do that

Re: [HACKERS] tap tests remove working directories

2015-08-07 Thread Andrew Dunstan
On 08/07/2015 05:11 PM, Tom Lane wrote: Andrew Dunstan writes: One of the things that makes the TAP tests very difficult and annoying to debug is their insistence on removing their data directories. I'm not sure why they are doing that. We don't do that with pg_regress. Instead we

[HACKERS] tap tests remove working directories

2015-08-07 Thread Andrew Dunstan
One of the things that makes the TAP tests very difficult and annoying to debug is their insistence on removing their data directories. I'm not sure why they are doing that. We don't do that with pg_regress. Instead we have clean targets to remove them if necessary. I suggest that we either dis

Re: [HACKERS] raw output from copy

2015-08-05 Thread Andrew Dunstan
On 08/05/2015 04:59 PM, Heikki Linnakangas wrote: On 07/27/2015 02:28 PM, Pavel Stehule wrote: 2015-07-27 10:41 GMT+02:00 Heikki Linnakangas : What about input? This is a whole new feature, but it would be nice to be able to pass the file contents as a query parameter. Something like: \P /t

Re: [HACKERS] upgrade failure from 9.5 to head

2015-08-04 Thread Andrew Dunstan
On 08/04/2015 02:09 PM, Tom Lane wrote: Robert Haas writes: On Tue, Aug 4, 2015 at 1:54 PM, Andres Freund wrote: On 2015-08-04 13:52:54 -0400, Tom Lane wrote: Not sure whether we should consider it a back-patchable bug fix or something to do only in HEAD, though --- comments? Tentatively I

Re: [HACKERS] upgrade failure from 9.5 to head

2015-08-02 Thread Andrew Dunstan
On 08/02/2015 04:00 PM, Tom Lane wrote: Andres Freund writes: On 2015-08-01 19:13:05 -0400, Noah Misch wrote: That's a bug. The test_ddl_deparse suite leaves a shell type, which pg_upgrade fails to reproduce. Whether to have pg_upgrade support that or just error out cleanly is another quest

Re: [HACKERS] upgrade failure from 9.5 to head

2015-08-01 Thread Andrew Dunstan
On 08/01/2015 07:13 PM, Noah Misch wrote: On Wed, Jul 29, 2015 at 04:42:55PM -0400, Andrew Dunstan wrote: The next hump is this, in restoring contrib_regression_test_ddl_parse: pg_restore: creating FUNCTION "public"."text_w_default_in("cstring")" pg_

Re: [HACKERS] TAP tests are badly named

2015-08-01 Thread Andrew Dunstan
On 08/01/2015 04:44 PM, Noah Misch wrote: --enable-tap-tests is a reasonable configuration setting, because it's about whether or not we have a TAP testing framework available, but I think we should stop calling the bin tests "TAP tests" and we should change the test name in vcregress.pl to a

Re: [HACKERS] TAP tests are badly named

2015-07-30 Thread Andrew Dunstan
On 07/30/2015 12:40 PM, Andrew Dunstan wrote: We should describe test sets by what they test, not by how they test. TAP is a testing tool/protocol. The current set of tests we have test the programs in src/bin, and we should really name the test set by a name that reflects that, rather than

[HACKERS] TAP tests are badly named

2015-07-30 Thread Andrew Dunstan
We should describe test sets by what they test, not by how they test. TAP is a testing tool/protocol. The current set of tests we have test the programs in src/bin, and we should really name the test set by a name that reflects that, rather than the fact that we are using TAP tools to run the

Re: [HACKERS] upgrade failure from 9.5 to head

2015-07-29 Thread Andrew Dunstan
On 07/29/2015 11:28 AM, Tom Lane wrote: Stephen Frost writes: * Tom Lane (t...@sss.pgh.pa.us) wrote: Really? What aspect of postgis requires mucking with shared_preload_libraries? Having to have the libraries in place is what I was getting at, which is what Andres was also talking about, if

[HACKERS] upgrade failure from 9.5 to head

2015-07-29 Thread Andrew Dunstan
My cross-version upgrade testing tool just threw up this failure, upgrading from 9.5 to head: CREATE ROLE "dummy_seclabel_user1"; CREATE ROLE ALTER ROLE "dummy_seclabel_user1" WITH NOSUPERUSER INHERIT CREATEROLE NOCREATEDB LOGIN NOREPLICATION NOBYPASSRLS; ALTER ROLE SECURITY

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

2015-07-28 Thread Andrew Dunstan
On 07/28/2015 08:58 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/27/2015 10:06 AM, Tom Lane wrote: I think we should disable TAP testing in the buildfarm until there is some credible form of error reporting for it. The situation should now be substantially improved. Hm, I was just

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

2015-07-28 Thread Andrew Dunstan
On 07/27/2015 12:15 PM, Andrew Dunstan wrote: On 07/27/2015 10:06 AM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi

Re: [HACKERS] Shouldn't we document "don't use a mountpoint as $PGDATA"?

2015-07-28 Thread Andrew Dunstan
On 07/28/2015 02:01 PM, Tom Lane wrote: I had a discussion with some folks at Red Hat about this: https://bugzilla.redhat.com/show_bug.cgi?id=1247477 I had the idea that we had documented somewhere that the data directory should not be a filesystem mount point, but I sure can't find it now. Any

Re: [HACKERS] proposal: multiple psql option -c

2015-07-28 Thread Andrew Dunstan
On 07/28/2015 11:52 AM, Pavel Stehule wrote: 2015-07-28 15:16 GMT+02:00 Andrew Dunstan <mailto:and...@dunslane.net>>: On 07/28/2015 12:08 AM, Pavel Stehule wrote: 2015-07-28 5:24 GMT+02:00 Pavel Stehule mailto:pavel.steh...@gmail.com> <ma

Re: [HACKERS] Improving log capture of TAP tests with IPC::Run

2015-07-28 Thread Andrew Dunstan
On 07/09/2015 06:29 AM, Heikki Linnakangas wrote: On 07/09/2015 04:50 AM, Michael Paquier wrote: Except that this patch looks good to me. Thanks for the black magic on stdout/stderr handling. Thanks, fixed the parenthesis and committed. The missing --debug is a separate issue. What wa

Re: [HACKERS] proposal: multiple psql option -c

2015-07-28 Thread Andrew Dunstan
On 07/28/2015 12:08 AM, Pavel Stehule wrote: 2015-07-28 5:24 GMT+02:00 Pavel Stehule <mailto:pavel.steh...@gmail.com>>: 2015-07-27 21:57 GMT+02:00 Andrew Dunstan mailto:and...@dunslane.net>>: On 07/27/2015 02:53 PM, Pavel Stehule wrote: I a

Re: [HACKERS] proposal: multiple psql option -c

2015-07-28 Thread Andrew Dunstan
On 07/28/2015 04:43 AM, Marc Mamin wrote: > > >2015-07-28 5:24 GMT+02:00 Pavel Stehule : > >2015-07-27 21:57 GMT+02:00 Andrew Dunstan : > >On 07/27/2015 02:53 PM, Pavel Stehule wrote: > >I am trying to run parallel execution > >

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-28 Thread Andrew Dunstan
On 07/27/2015 03:52 AM, Marc Mamin wrote: As per attached patch. Comments? It seems that the first test on the compression in pg_backup_tar.c is now obsolete. It didn't make much sense anyway. 211 if (AH->compression < 0 || AH->compression > 9) 212 AH->compressi

Re: [HACKERS] proposal: multiple psql option -c

2015-07-27 Thread Andrew Dunstan
On 07/27/2015 02:53 PM, Pavel Stehule wrote: I am trying to run parallel execution psql -At -c "select datname from pg_database" postgres | xargs -n 1 -P 3 psql -c "select current_database()" I don't think it's going to be a hugely important feature, but I don't see a problem with c

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

2015-07-27 Thread Andrew Dunstan
On 07/27/2015 10:06 AM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-07-04%2016%3A00%3A23 or here: h

Re: [HACKERS] Buildfarm failure from overly noisy warning message

2015-07-26 Thread Andrew Dunstan
On 07/26/2015 11:00 AM, Andres Freund wrote: Hi, On 2015-07-26 10:56:05 -0400, Tom Lane wrote: CREATE INDEX tenk2_unique1 ON tenk2 USING btree(unique1 int4_ops); + WARNING: could not send signal to process 30123: No such process What's evidently happened here is that our session tried to b

Re: [HACKERS] Debugging buildfarm pg_upgrade check failures

2015-07-25 Thread Andrew Dunstan
On 07/25/2015 10:59 AM, Tom Lane wrote: Now that we've restored proper logging of "make check", I looked into today's failure report from axolotl: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2015-07-24%2020%3A29%3A18 What evidently happened there is that "pg_ctl start" gav

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-25 Thread Andrew Dunstan
On 07/25/2015 03:07 PM, Marc Mamin wrote: I propose to tighten pg_dump's rules so that only 0..9 are accepted as arguments for -Z, and in compress_io.c:cfopen(), if compression is equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value to the mode, thus using the zlib default.

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-25 Thread Andrew Dunstan
On 07/25/2015 01:52 PM, I wrote: I propose to tighten pg_dump's rules so that only 0..9 are accepted as arguments for -Z, and in compress_io.c:cfopen(), if compression is equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value to the mode, thus using the zlib default.

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-25 Thread Andrew Dunstan
On 07/25/2015 10:50 AM, Michael Paquier wrote: On Sat, Jul 25, 2015 at 11:09 PM, Marc Mamin wrote: On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan wrote: On 07/25/2015 03:20 AM, Andrew Dunstan wrote: On 07/25/2015 02:34 AM, Marc Mamin wrote: Andrew Dunstan writes: Hmm. Yeah. It looks

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-25 Thread Andrew Dunstan
On 07/25/2015 03:20 AM, Andrew Dunstan wrote: On 07/25/2015 02:34 AM, Marc Mamin wrote: Andrew Dunstan writes: Hmm. Yeah. It looks like commit a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911 changed from using the default compression for libz to using the compression set in pg_dump options

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-25 Thread Andrew Dunstan
On 07/25/2015 02:34 AM, Marc Mamin wrote: Andrew Dunstan writes: Hmm. Yeah. It looks like commit a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911 changed from using the default compression for libz to using the compression set in pg_dump options, which defaults to 0. This actually seems like the

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-24 Thread Andrew Dunstan
On 07/24/2015 05:22 PM, Marc Mamin wrote: After our last upgrade, we've noticed a 10-20% size increase of our dump size. This comes from our backup scripts were pg_dump was called without setting -Z So it seems, that this fix did modify the default compression to use: http://michael.otacoo.com/

Re: [HACKERS] pg_dump -Fd and compression level

2015-07-24 Thread Andrew Dunstan
On 07/24/2015 02:52 AM, Marc Mamin wrote: Hello, After our last upgrade, we've noticed a 10-20% size increase of our dump size. This comes from our backup scripts were pg_dump was called without setting -Z So it seems, that this fix did modify the default compression to use: http://michael.ota

Re: [HACKERS] Supporting TAP tests with MSVC and Windows

2015-07-24 Thread Andrew Dunstan
On 07/24/2015 01:27 PM, Heikki Linnakangas wrote: On 06/25/2015 07:40 AM, Michael Paquier wrote: On Tue, May 26, 2015 at 3:39 PM, Michael Paquier wrote: Here is v6, a rebased version on HEAD (79f2b5d). There were some conflicts with the indentation and some other patches related to pg_rewind a

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

2015-07-24 Thread Andrew Dunstan
On 07/24/2015 01:21 PM, Jeff Janes wrote: On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier mailto:michael.paqu...@gmail.com>> wrote: On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut mailto:pete...@gmx.net>> wrote: > On 7/21/15 10:00 AM, Tom Lane wrote: >> I agree; this change

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

2015-07-21 Thread Andrew Dunstan
On 07/21/2015 01:39 AM, Michael Paquier wrote: On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane wrote: Andrew Dunstan writes: Somewhere along the way some changes to the way we do "make check" have caused a significant deterioration in the buildfarm's logging. Compare these two fr

[HACKERS] "make check" changes have caused buildfarm deterioration.

2015-07-20 Thread Andrew Dunstan
Somewhere along the way some changes to the way we do "make check" have caused a significant deterioration in the buildfarm's logging. Compare these two from animal crake, which happens to be my test instance:

Re: [HACKERS] Further issues with jsonb semantics, documentation

2015-07-17 Thread Andrew Dunstan
On 07/17/2015 02:49 PM, Andrew Dunstan wrote: On 07/17/2015 02:37 PM, Robert Haas wrote: On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan wrote: Where are we on this? This is currently a 9.5 release blocker. I am on vacation right now, but I might have some time tomorrow to deal with it

Re: [HACKERS] Further issues with jsonb semantics, documentation

2015-07-17 Thread Andrew Dunstan
On 07/17/2015 02:37 PM, Robert Haas wrote: On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan wrote: Where are we on this? This is currently a 9.5 release blocker. I am on vacation right now, but I might have some time tomorrow to deal with it. If not, it will be Sunday or Monday when I get to

Re: [HACKERS] [PATCH] Generalized JSON output functions

2015-07-17 Thread Andrew Dunstan
On 07/17/2015 10:30 AM, Alvaro Herrera wrote: Andrew Dunstan wrote: I have already pointed out how this patch is fundamentally broken. You can achieve your aims by a fairly small amount of code inside your logical decoder, and with no core code changes whatsoever. So I'm puzzled why w

Re: [HACKERS] [PATCH] Generalized JSON output functions

2015-07-17 Thread Andrew Dunstan
On 07/17/2015 10:11 AM, Andrew Dunstan wrote: On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote: > This patch makes Postgres core more complex Yes, it does. But, that was not the purpose, obviously. :-) > while not really solving the problem in Javascript. It still allows for less r

Re: [HACKERS] [PATCH] Generalized JSON output functions

2015-07-17 Thread Andrew Dunstan
On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote: > This patch makes Postgres core more complex Yes, it does. But, that was not the purpose, obviously. :-) > while not really solving the problem in Javascript. It still allows for less risk of silent data corruption on the js side. I hav

Re: [HACKERS] [PATCH] Generalized JSON output functions

2015-07-15 Thread Andrew Dunstan
On 07/15/2015 10:52 AM, Robert Haas wrote: On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela wrote: As far as large numbers in JSON, I think Postgres is doing the right thing and should not be changed. It is Javascript that is stupid here, and I don't think it is wise to add something to core just

Re: [HACKERS] Implementation of global temporary tables?

2015-07-15 Thread Andrew Dunstan
On 07/15/2015 07:58 AM, Simon Riggs wrote: For me the design summary is this * CREATE GLOBAL TEMP TABLE creates catalog entries like a normal table but with different relkind * When we see a request to INSERT, DEL, UPD, SEL from the temp table, if it does not exist we create it as a TEMP ta

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

2015-07-13 Thread Andrew Dunstan
On 07/13/2015 07:55 PM, Michael Paquier wrote: On Tue, Jul 14, 2015 at 8:49 AM, Andrew Dunstan wrote: On 07/13/2015 07:33 PM, Tom Lane wrote: Andrew Dunstan writes: Not AFAICT. Here is the contrib build: Hm ... what does -DUSE_DL_IMPORT do? NFI - I tried building with that but it made no

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

2015-07-13 Thread Andrew Dunstan
On 07/13/2015 07:33 PM, Tom Lane wrote: Andrew Dunstan writes: Not AFAICT. Here is the contrib build: Hm ... what does -DUSE_DL_IMPORT do? NFI - I tried building with that but it made no difference. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

2015-07-13 Thread Andrew Dunstan
On 07/13/2015 05:18 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/13/2015 11:53 AM, Marco Atzeri wrote: On 7/13/2015 5:36 PM, Andrew Dunstan wrote: hstore_plpython.o: In function `hstore_to_plpython': /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

2015-07-13 Thread Andrew Dunstan
On 07/13/2015 11:53 AM, Marco Atzeri wrote: On 7/13/2015 5:36 PM, Andrew Dunstan wrote: On 07/12/2015 05:06 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/04/2015 11:02 AM, Tom Lane wrote: It's not apparent to me how that works at all. BTW, the .a files being linked to above ar

Re: [HACKERS] pg_upgrade + Extensions

2015-07-13 Thread Andrew Dunstan
On 07/13/2015 01:12 PM, Smitha Pamujula wrote: Yes. I have checked that the extension didn't exist in any of the databases. I used \dx to see if there was json_build was listed and i didnt see any. Is that sufficient to check its existence. I am about to do another testing in a few minutes on

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

2015-07-13 Thread Andrew Dunstan
On 07/12/2015 05:06 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/04/2015 11:02 AM, Tom Lane wrote: It's not apparent to me how that works at all. BTW, the .a files being linked to above are not like Unix .a static archives - they are import library files, which I think they are

Re: [HACKERS] [PATCH] Generalized JSON output functions

2015-07-13 Thread Andrew Dunstan
On 07/13/2015 10:46 AM, Ryan Pedela wrote: On Mon, Jul 13, 2015 at 1:30 AM, Shulgin, Oleksandr mailto:oleksandr.shul...@zalando.de>> wrote: To reiterate: for my problem, that is escaping numerics that can potentially overflow[1] under ECMAScript standard, I want to be able to ove

Re: [HACKERS] [PATCH] Generalized JSON output functions

2015-07-13 Thread Andrew Dunstan
On 07/13/2015 05:41 AM, Shulgin, Oleksandr wrote: On Mon, Jul 13, 2015 at 9:44 AM, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote: To reiterate: for my problem, that is escaping numerics that can potentially overflow[1] under ECMAScript standard, I want to be abl

<    1   2   3   4   5   6   7   8   9   10   >