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

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't

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

On 09/09/2015 10:27 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> 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 tha

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

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 argument

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

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 define it. The attached

Re: [HACKERS] exposing pg_controldata and pg_config as functions

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 that use

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

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

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

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

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

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

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

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

Re: [HACKERS] exposing pg_controldata and pg_config as functions

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

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

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

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

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

Re: [HACKERS] perlcritic

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

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

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__)

Re: [HACKERS] pg_upgrade + Extensions

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.

Re: [HACKERS] pg_upgrade + Extensions

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 <br...@momjian.us> wrote: I think it would help if its noted somewhere in the do

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

On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: On Sat, Aug 29, 2015 at 8:39 AM, Pavel Stehule pavel.steh...@gmail.com mailto:pavel.steh...@gmail.com wrote: Hi currently JSON support NULL value - but we doesn't convert NULL to JSON correctly postgres=# select

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

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

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

On 08/29/2015 04:27 PM, Tom Lane wrote: Jim Nasby jim.na...@bluetreble.com 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

Re: [HACKERS] Function accepting array of complex type

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

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.4arch=alphaver=9.4.4-1stamp=1434132509 make[5]: Entering directory '/«PKGBUILDDIR»/build/src/backend/postmaster' [...] gcc -Wall -Wmissing-prototypes

Re: [HACKERS] 9.4 broken on alpha

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. cheers

Re: [HACKERS] Declarative partitioning

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

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

Re: [HACKERS] exposing pg_controldata and pg_config as functions

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

Re: [HACKERS] TAP tests are badly named

On 08/16/2015 08:30 PM, Michael Paquier wrote: On Mon, Aug 17, 2015 at 7:15 AM, Noah Misch n...@leadboat.com 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

[HACKERS] exposing pg_controldata and pg_config as functions

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

Re: [HACKERS] jsonb array-style subscripting

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 other

Re: [HACKERS] jsonb array-style subscripting

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 stdin, line 1, in module KeyError: 'a1' Not

Re: [HACKERS] jsonb array-style subscripting

On 08/18/2015 01:32 AM, Pavel Stehule wrote: Hi 2015-08-17 21:12 GMT+02:00 Jim Nasby jim.na...@bluetreble.com mailto:jim.na...@bluetreble.com: On 8/17/15 12:57 PM, Dmitry Dolgov wrote: * is it interesting for the community? We definitely need better ways to manipulate

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

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

Re: [HACKERS] More WITH

On 08/17/2015 01:30 PM, Peter Geoghegan wrote: On Mon, Aug 17, 2015 at 10:22 AM, Josh Berkus j...@agliodbs.com 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

Re: [HACKERS] jsonb array-style subscripting

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

Re: [HACKERS] TAP tests are badly named

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:

Re: [HACKERS] TAP tests are badly named

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. I

Re: [HACKERS] buildfarm does not test make check

On 08/14/2015 09:27 AM, Robert Haas wrote: On Thu, Aug 13, 2015 at 2:11 PM, Alvaro Herrera alvhe...@alvh.no-ip.org 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

Re: [HACKERS] TAP tests are badly named

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 chose

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

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

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

On 08/14/2015 02:10 PM, Peter Geoghegan wrote: On Fri, Aug 14, 2015 at 10:28 AM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] TAP tests are badly named

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 tests and we

Re: [HACKERS] buildfarm does not test make check

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

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

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

Re: [HACKERS] buildfarm does not test make check

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

Re: [HACKERS] TAP tests are badly named

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 extensions

Re: [HACKERS] tap tests remove working directories

On 08/10/2015 09:55 AM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] tap tests remove working directories

On 08/10/2015 10:32 AM, Andrew Dunstan wrote: On 08/10/2015 09:55 AM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

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

On 08/10/2015 07:29 PM, Tom Lane wrote: I wrote: Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] tap tests remove working directories

On 08/09/2015 08:58 PM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 11:19 PM, Andrew Dunstan and...@dunslane.net wrote: On 08/09/2015 08:41 AM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan and...@dunslane.net wrote: On 08/08/2015 09:31 AM, Robert Haas wrote

Re: [HACKERS] tap tests remove working directories

On 08/09/2015 08:41 AM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan and...@dunslane.net wrote: On 08/08/2015 09:31 AM, Robert Haas wrote: On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dunstan and...@dunslane.net wrote: That certainly isn't what happens, and given the way

Re: [HACKERS] tap tests remove working directories

On 08/08/2015 09:31 AM, Robert Haas wrote: On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] Test code is worth the space

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

Re: [HACKERS] tap tests remove working directories

On 08/07/2015 05:11 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

[HACKERS] tap tests remove working directories

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

Re: [HACKERS] raw output from copy

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 hlinn...@iki.fi: 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.

Re: [HACKERS] upgrade failure from 9.5 to head

On 08/04/2015 02:09 PM, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Aug 4, 2015 at 1:54 PM, Andres Freund and...@anarazel.de 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

Re: [HACKERS] upgrade failure from 9.5 to head

On 08/02/2015 04:00 PM, Tom Lane wrote: Andres Freund and...@anarazel.de 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

Re: [HACKERS] upgrade failure from 9.5 to head

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_restore: [archiver (db)] Error while

Re: [HACKERS] TAP tests are badly named

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

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

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

Re: [HACKERS] upgrade failure from 9.5 to head

On 07/29/2015 11:28 AM, Tom Lane wrote: Stephen Frost sfr...@snowman.net 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

[HACKERS] upgrade failure from 9.5 to head

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

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=hornetdt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl

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

On 07/28/2015 08:58 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

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

On 07/28/2015 04:43 AM, Marc Mamin wrote: 2015-07-28 5:24 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com: 2015-07-27 21:57 GMT+02:00 Andrew Dunstan and...@dunslane.net: On 07/27/2015 02:53 PM, Pavel Stehule wrote: I am trying to run parallel execution

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

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

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

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

Re: [HACKERS] pg_dump -Fd and compression level

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-compression =

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

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=hornetdt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamsterdt=2015-07-04%2016%3A00%3A23 or here:

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

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

Re: [HACKERS] pg_dump -Fd and compression level

On 07/25/2015 02:34 AM, Marc Mamin wrote: Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] pg_dump -Fd and compression level

On 07/25/2015 10:50 AM, Michael Paquier wrote: On Sat, Jul 25, 2015 at 11:09 PM, Marc Mamin m.ma...@intershop.de wrote: On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan and...@dunslane.net wrote: On 07/25/2015 03:20 AM, Andrew Dunstan wrote: On 07/25/2015 02:34 AM, Marc Mamin wrote

Re: [HACKERS] Debugging buildfarm pg_upgrade check failures

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=axolotldt=2015-07-24%2020%3A29%3A18 What evidently happened there is that pg_ctl start gave up

Re: [HACKERS] pg_dump -Fd and compression level

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

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

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

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

On 07/24/2015 01:21 PM, Jeff Janes wrote: On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier michael.paqu...@gmail.com mailto:michael.paqu...@gmail.com wrote: On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut pete...@gmx.net mailto:pete...@gmx.net wrote: On 7/21/15 10:00 AM, Tom

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

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

Re: [HACKERS] pg_dump -Fd and compression level

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:

Re: [HACKERS] pg_dump -Fd and compression level

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:

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

On 07/21/2015 01:39 AM, Michael Paquier wrote: On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan andrew.duns...@pgexperts.com writes: Somewhere along the way some changes to the way we do make check have caused a significant deterioration in the buildfarm's

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

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 risk

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

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 have

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

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 we

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

On 07/17/2015 02:37 PM, Robert Haas wrote: On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan and...@dunslane.net 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

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

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 and...@dunslane.net 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

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

On 07/15/2015 10:52 AM, Robert Haas wrote: On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela rped...@datalanche.com 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

Re: [HACKERS] Implementation of global temporary tables?

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

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

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

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

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

Re: [HACKERS] pg_upgrade + Extensions

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

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 and...@dunslane.net 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

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

On 07/13/2015 07:33 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

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

On 07/12/2015 05:06 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

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

On 07/13/2015 05:18 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

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

On 07/13/2015 07:55 PM, Michael Paquier wrote: On Tue, Jul 14, 2015 at 8:49 AM, Andrew Dunstan and...@dunslane.net wrote: On 07/13/2015 07:33 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Not AFAICT. Here is the contrib build: Hm ... what does -DUSE_DL_IMPORT do? NFI - I

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

On 07/04/2015 01:09 PM, Andrew Dunstan wrote: On 07/04/2015 11:02 AM, Tom Lane wrote: Marco Atzeri marco.atz...@gmail.com writes: for what I see the hstore_plperl link has a double problem. It requires a link to hstore as it also requires a link to perl. Attached patch for solving

Re: [HACKERS] pg_upgrade + Extensions

On Fri, Jul 10, 2015 at 5:05 PM, David E. Wheeler da...@justatheory.com wrote: On Jul 10, 2015, at 11:32 AM, Smitha Pamujula smitha.pamuj...@iovation.com wrote: Your installation references loadable libraries that are missing from the new installation. You can add these libraries to the

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

On 07/09/2015 04:10 AM, Peter Geoghegan wrote: On Mon, Jun 22, 2015 at 6:19 PM, Peter Geoghegan p...@heroku.com wrote: On Wed, Jun 10, 2015 at 11:48 AM, Andrew Dunstan and...@dunslane.net wrote: Please submit a patch to adjust the treatment of negative integers in the old functions

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

On 07/04/2015 11:02 AM, Tom Lane wrote: I wondered how come we had not seen this problem in the buildfarm, but the answer appears to be that our only working Cygwin critter (brolga) doesn't build any of the optional PLs, so it skips these modules altogether. Seems like we need to improve that

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