Re: [HACKERS] btree_gin and btree_gist for enums

On 11/04/2016 04:14 PM, Emre Hasegeli wrote: The GiST part of it doesn't really work. The current patch compares oids. We need to change it to compare enumsortorder. I could make it fail easily: regression=# create type e as enum ('0', '2', '3'); CREATE TYPE regression=# alter type e add

Re: [HACKERS] btree_gin and btree_gist for enums

On 11/04/2016 04:14 PM, Emre Hasegeli wrote: Here is a patch to add enum support to btree_gin and btree_gist. I didn't include distance operations, as I didn't think it terribly important, and there isn't a simple way to compute it sanely and efficiently, so no KNN support. I don't think we

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

On 10/28/2016 03:14 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? That won't get us out of the O(N^2) behavior. Also I don't see what's better about it t

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

On 10/28/2016 02:04 PM, Tom Lane wrote: Comments, better ideas? My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

On 10/17/2016 09:57 AM, Aleksander Alekseev wrote: Hello. Sometimes it's useful to log content of files used in COPY ... TO ... and COPY ... FROM ... queries. Unfortunately PostgreSQL doesn't allow to do it, even if log_statement='all'. Suggested patch fixes this. Log example: ``` LOG:

[HACKERS] buildfarm client release 4.18

I have just released buildfarm client version 4.18. In addition to some minor fixes, there are two significant changes: * The client now makes a determined effort to clean up any left over build artefacts from previous runs at the start of a run. It also tries to clean away old socket

[HACKERS] cygwin64 assertion failure

lorikeet seems to be stuck running the parallel tests, after having failed an assertion. Here's an excerpt from the log: 2016-10-09 11:52:35.751 EDT [57fa67c3.1148:11] LOG: statement: alter table tenk1 set (parallel_workers = 4); 2016-10-09 11:52:35.753 EDT [57fa67c3.1148:12] LOG:

Re: [HACKERS] Misidentification of Python shared library

On 10/04/2016 10:43 AM, Tom Lane wrote: While chasing down last night's failure on buildfarm member longfin, I came across an interesting factoid. If you just do ./configure --enable-shared make make install in unmodified Python sources, what you will get is an

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 07:21 PM, Tom Lane wrote: I wrote: It occurs to me that a back-patchable workaround for this would be to make get_loadable_libraries sort the library names in order by length (and I guess we might as well sort same-length names alphabetically). This would for example guarantee

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 12:54 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: The biggest issue is this: the upgrade fails completely on ltree-plpython and hstore-plpython, presumably because these modules rely on the plpython module being loaded first. pg_upgrade rather

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 01:53 PM, Tom Lane wrote: So then why are the pre-upgrade and post-upgrade dumps different? Because pg_dump with --binary-upgrade neglects to emit ALTER EXTENSION bloom ADD ACCESS METHOD bloom; That's what I suspected. which it would need to do in order to make this work

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 09:50 AM, Michael Paquier wrote: On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan <and...@dunslane.net> wrote: It looks like we have some work to do to teach pg_dump about handling access methods in extensions. This doesn't look quite as bad as the first issue, but it's

[HACKERS] pg_upgade vs config

I'm working on updating and making production ready my experimental cross version pg_upgrade testing module for the buildfarm. A couple of things have emerged that are of concern. This module does a much more complete test that our normal test for pg_upgrade, which only checks upgrading the

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 10/01/2016 02:01 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: On 09/30/2016 12:24 PM, Tom Lane wrote: Seems to be some additional prep work needed somewhere ... No upgrade_install_root at /home/bfarm/bf-scripts/build-farm-4.17/PGBuild/Modules/TestUpgradeXvers

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 09/30/2016 12:24 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: On 09/30/2016 10:25 AM, Tom Lane wrote: Oh! How would I enable or use that? 1. Pull the latest version of the module from git. 2. enable it in your buildfarm config file 3. do "run_branches.p

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 09/30/2016 10:25 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: On 09/29/2016 05:48 PM, Tom Lane wrote: We might've caught these things earlier if the buildfarm testing included cross-version upgrades, but of course that requires a lot of test infrastructure

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 09/29/2016 05:48 PM, Tom Lane wrote: We might've caught these things earlier if the buildfarm testing included cross-version upgrades, but of course that requires a lot of test infrastructure that's not there ... I have done quite a bit of work on this - see

Re: [HACKERS] pg_upgrade vs user created range type extension

On 09/23/2016 11:55 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: On 09/22/2016 07:33 PM, Tom Lane wrote: If that diagnosis is correct, we should either change pg_dump to not dump that function, or change CREATE TYPE AS RANGE to not auto-create the constructor fun

Re: [HACKERS] pg_upgrade vs user created range type extension

On 09/22/2016 07:33 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: I have just encountered an apparent bug in pg_upgrade (or possibly pg_dump). Hmm, it sort of looks like pg_dump believes it should dump the range's constructor function in binary-upgrade mode,

[HACKERS] pg_upgrade vs user created range type extension

I have just encountered an apparent bug in pg_upgrade (or possibly pg_dump). To recreate, install the cranges extension - which can be obtained via "git clone https://bitbucket.org/adunstan/pg-closed-ranges.git; - for both 9.4 and 9.5. Create a fresh 9.4 instance, create a database and in

Re: [HACKERS] [PATCH] pgpassfile connection option

On 09/22/2016 10:44 AM, Julian Markwort wrote: Hello psql-hackers! We thought it would be advantageous to be able to specify a 'custom' pgpassfile within the connection string along the lines of the existing parameters sslkey and sslcert. Which is exactly what this very compact patch

Re: [HACKERS] [PATCH] Alter or rename enum value

On 09/06/2016 02:30 PM, Tom Lane wrote: Robert Haas writes: On Mon, Sep 5, 2016 at 11:40 PM, Tom Lane wrote: ... And again, it's hard to get excited about having these options for RENAME VALUE when no one has felt a need for them yet in RENAME

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On 08/15/2016 02:23 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: We should probably specify -bext='/', which would cause the backup files to be deleted unless an error occur

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: On 08/14/2016 04:38 PM, Tom Lane wrote: I did a trial run following the current pgindent README procedure, and noticed that the perltidy step left me with a pile of '.bak' files littering the entir

Re: [HACKERS] Why --backup-and-modify-in-place in perltidy config?

On 08/14/2016 04:38 PM, Tom Lane wrote: I did a trial run following the current pgindent README procedure, and noticed that the perltidy step left me with a pile of '.bak' files littering the entire tree. This seems like a pretty bad idea because a naive "git add ." would have committed them.

Re: [HACKERS] New version numbering practices

On 08/01/2016 04:25 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: Somewhat related is how we name the git branches. It would help me from a buildfarm POV if we kept lexically them sortable, which could be done at least for the next 90 major releases :-) by

Re: [HACKERS] New version numbering practices

On 08/01/2016 11:49 AM, Tom Lane wrote: Also, it strikes me that we need a new convention for how we talk about release branches informally. Up to now, mentioning say "9.5" without any further qualification in a PG-list message was usually sufficient to indicate a branch number, but I do not

Re: [HACKERS] fixes for the Danish locale

On 07/21/2016 02:26 PM, Greg Stark wrote: On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane wrote: Confirmed here. Will deal with it, but I wonder why we have no buildfarm members covering this ... We're not going to have a build farm member for every locale the local systems

Re: [HACKERS] sslmode=require fallback

On 07/15/2016 09:55 AM, Tom Lane wrote: I'm inclined to think that a better answer than changing libpq's behavior is to encourage DBAs to specify "hostssl" in pg_hba.conf for all external connections. Do those packagers who install dummy certificates and turn SSL on also change their

Re: [HACKERS] WIP: About CMake v2

On 06/30/2016 03:13 AM, Yury Zhuravlev wrote: Michael Paquier wrote: You have not tested with macOS, and so did I. Thanks! I fixed this typo. But for XCode I see more corrections. I will can fix it today or maybe tomorrow. It would be nice to come as well with simpler steps than all

Re: [HACKERS] WIP: About CMake v2

On 06/30/2016 06:26 AM, Oleg Bartunov wrote: On Wed, Jun 29, 2016 at 7:23 PM, Yury Zhuravlev wrote: Hello Hackers. I decided to talk about the current state of the project: 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all work correctly

[HACKERS] pager_min_lines tab completion

I have just noticed that when I added the pager_min_lines psetting to psql in 9.5, I omitted to add it to the relevant piece of tab-complete.c. If no-one objects I propose to remedy that shortly and backpatch it. cheers andrew -- Sent via pgsql-hackers mailing list

Re: [HACKERS] 10.0

On 05/13/2016 05:12 PM, Tom Lane wrote: An analogy that might get some traction among database geeks is that version numbers are a sort of surrogate key, and assigning meaning to surrogate keys is a bad idea. :-) I agree year-based numbers will cause us grief. I

Re: [HACKERS] Does Type Have = Operator?

On 05/12/2016 03:02 PM, Tom Lane wrote: "David E. Wheeler" writes: Some might argue that it ought to compare JSON objects, effectively be the equivalent of ::jsonb = ::jsonb, rather than ::text = ::text. But as Andrew points out to me offlist, “if that's what they

Re: [HACKERS] [COMMITTERS] pgsql: Disable BLOB test in pg_dump TAP tests

On 05/08/2016 12:52 AM, Stephen Frost wrote: Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost writes: Disable BLOB test in pg_dump TAP tests Buildfarm member jacana appears to have an issue with running this test. It's not entirely clear to me why, but rather

Re: [HACKERS] ALTER TABLE lock downgrades have broken pg_upgrade

On 05/03/2016 01:58 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: And if this is of any use, here are the dump differences from every live version to git tip, as of this morning. Interesting, thanks. I wonder if some of these diffs could be reduced further by using pg_dump -Fd instead

Re: [HACKERS] ALTER TABLE lock downgrades have broken pg_upgrade

On 05/03/2016 01:33 PM, Andrew Dunstan wrote: On 05/03/2016 01:28 PM, Andrew Dunstan wrote: On 05/03/2016 01:21 PM, Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Tom Lane wrote: More generally, though, I wonder how we can have some test coverage on such cases

Re: [HACKERS] ALTER TABLE lock downgrades have broken pg_upgrade

On 05/03/2016 01:28 PM, Andrew Dunstan wrote: On 05/03/2016 01:21 PM, Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Tom Lane wrote: More generally, though, I wonder how we can have some test coverage on such cases going forward. Is the patch below too ugly

Re: [HACKERS] ALTER TABLE lock downgrades have broken pg_upgrade

On 05/03/2016 01:21 PM, Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Tom Lane wrote: More generally, though, I wonder how we can have some test coverage on such cases going forward. Is the patch below too ugly to commit permanently, and if so, what other idea can

Re: [HACKERS] pgindent fixups

On 05/02/2016 10:56 PM, Robert Haas wrote: I spent some time going through the output of a trial pgindent run today. Some questions/problems: 1. Is pgindent supposed to touch DATA() lines? Because it does. Apart from being detabbed/entabbed, no. pgindent protects (or tries to protect)

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On 05/02/2016 04:56 AM, Shulgin, Oleksandr wrote: On Sun, May 1, 2016 at 3:22 AM, Andrew Dunstan <and...@dunslane.net <mailto:and...@dunslane.net>> wrote: On 04/29/2016 06:11 PM, Merlin Moncure wrote: This is a simple matter of removing spaces in the occasional C

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On 04/29/2016 06:11 PM, Merlin Moncure wrote: This is a simple matter of removing spaces in the occasional C string literal in the serialization routines and adding a json_pretty function. I spent a few hours on this. See

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On 04/29/2016 02:34 PM, Merlin Moncure wrote: I wouldn't necessarily be opposed to us having one or more of the following: a) suppressing whitespace addition in all json generation and text output, possibly governed by a GUC setting so we could maintain behaviour compatibility if required

Re: [HACKERS] pgsql: Support building with Visual Studio 2015

On 04/29/2016 09:29 AM, Christian Ullrich wrote: * Andrew Dunstan wrote: Support building with Visual Studio 2015 http://git.postgresql.org/pg/commitdiff/da52474f3d3cbdf38d8a6677a4ebedaf402ade3a diff --git a/src/port/win32env.c b/src/port/win32env.c index 7e4ff62..d6b0ebe 100644 (file

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On 04/28/2016 04:29 PM, Alvaro Herrera wrote: David G. Johnston wrote: On Thu, Apr 28, 2016 at 10:00 AM, Ryan Pedela wrote: In addition, every JSON implementation I have ever seen fully minimizes JSON by default. PG appears to deviate from standard practice for no

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/29/2016 12:39 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: latest patch attached. I have also cleaned up the docs some, and removed references to the now redundant msysGit. Please don't do stuff like this: @@ -232,6 +265,10 @@ win32_langinfo(const char

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/25/2016 03:11 AM, Michael Paquier wrote: On Mon, Apr 25, 2016 at 4:29 AM, Christian Ullrich wrote: Andrew wrote: OK, here's my final version of the patch, which I will apply in 24 hours or so unless there is an objection. Thanks Andrew for the updated patch!

[HACKERS] Re: [COMMITTERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013

On 04/25/2016 09:27 AM, Christian Ullrich wrote: * Magnus Hagander wrote: On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich wrote: * Magnus Hagander wrote: Add putenv support for msvcrt from Visual Studio 2013

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On 04/24/2016 06:02 PM, Sehrope Sarkuni wrote: AFAIK, there's also no guarantee on the specific order of the resulting properties in the text representation either. I would suppose it's fixed for a given jsonb value within a database major version but across major versions it could change

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/24/2016 03:16 PM, Christian Ullrich wrote: * Andrew Dunstan wrote: On 04/24/2016 12:14 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: OK, here's my final version of the patch, which I will apply in 24 hours or so unless there is an objection. BTW, i

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

On 04/02/2016 01:20 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: Looking at this briefly. It looks like the check should be called from enum_in() and enum_recv(). What error should be raised if the enum row's xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/24/2016 12:14 PM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: OK, here's my final version of the patch, which I will apply in 24 hours or so unless there is an objection. BTW, in view of 9f633b404, shouldn't there be a similar addition to win32env.c in this

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/24/2016 11:58 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: OK, here's my final version of the patch, which I will apply in 24 hours or so unless there is an objection. +#pragma warning(push) +#pragma warning(disable : 4091) #include +#pragma warning(pop

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/23/2016 11:25 PM, Andrew Dunstan wrote: On 04/23/2016 06:33 PM, Tom Lane wrote: I wrote: Andrew Dunstan <and...@dunslane.net> writes: On 04/23/2016 05:30 PM, Christian Ullrich wrote: In this case, I would prefer this: #ifdef WIN32_ONLY_COMPILER -typedef int pid_t; +t

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/23/2016 06:33 PM, Tom Lane wrote: I wrote: Andrew Dunstan <and...@dunslane.net> writes: On 04/23/2016 05:30 PM, Christian Ullrich wrote: In this case, I would prefer this: #ifdef WIN32_ONLY_COMPILER -typedef int pid_t; +typedef intptr_t pid_t; #endif That's a change that wil

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/23/2016 05:30 PM, Christian Ullrich wrote: * Andrew Dunstan wrote: On 04/22/2016 01:21 AM, Michael Paquier wrote: 5. It also complains about us casting a pid_t to a HANDLE in pg_basebackup.c. Not sure what to do about that. The thing that's being cast is not a PID, but a HANDLE

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/22/2016 01:21 AM, Michael Paquier wrote: 5. It also complains about us casting a pid_t to a HANDLE in pg_basebackup.c. Not sure what to do about that. The thing that's being cast is not a PID, but a HANDLE to a process. pid_t is a typedef for int (in port/win32.h), therefore is always

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/22/2016 02:46 AM, Michael Paquier wrote: Progress report: 1. My VS 2015 installations (I now have several) all generate solution file with: Microsoft Visual Studio Solution File, Format Version 12.00 so I propose to set that as the solution file version. I am wondering why it

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/21/2016 05:15 PM, Tom Lane wrote: IIRC, we had intentionally left contrib/seg using mostly V0 calling convention as a canary to let us know when that broke. It's a bit astonishing that it lasted this long, maybe. But it looks like we're going to have to convert at least the

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/11/2016 03:47 AM, Michael Paquier wrote: On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier wrote: Now, I have produced two patches: - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of __crt_locale_data_public in ucrt/corecrt.h. This is definitely

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/19/2016 01:47 AM, Michael Paquier wrote: On Tue, Apr 19, 2016 at 2:42 PM, Alvaro Herrera wrote: Michael Paquier wrote: On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier wrote: Now, I have produced two patches: -

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/09/2016 08:43 AM, Christian Ullrich wrote: Michael Paquier wrote: On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich <ch...@chrullrich.net> wrote: * Andrew Dunstan wrote: On 04/08/2

Re: [HACKERS] the buildfarm has measles

On 04/08/2016 10:38 PM, Andrew Dunstan wrote: On 04/08/2016 07:57 PM, Robert Haas wrote: bowerbird and lorikeet are complaining about the git tree being dirty. bowerbird is fixed and rebuilding. lorikeet should be fixed, too. But bowerbird failed compiling an Assert from commit

Re: [HACKERS] the buildfarm has measles

On 04/08/2016 07:57 PM, Robert Haas wrote: bowerbird and lorikeet are complaining about the git tree being dirty. bowerbird is fixed and rebuilding. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] raw output from copy

On 04/08/2016 02:13 PM, Robert Haas wrote: On Tue, Apr 5, 2016 at 4:45 AM, Pavel Stehule wrote: here is cleaned/finished previous implementation of RAW_TEXT/RAW_BINARY formats for COPY statements. The RAW with text formats means unescaped data, but with correct

Re: [HACKERS] Lower msvc build verbosity level

On 04/08/2016 12:24 PM, Christian Ullrich wrote: * Tom Lane wrote: +several. Grepping for compiler warnings, for example, is really painful right now on any MSVC critter. I've resorted to grepping for "warning C", which skips the noise messages, but I'm never sure if I'm missing

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/08/2016 11:02 AM, Christian Ullrich wrote: * Michael Paquier wrote: On Fri, Apr 8, 2016 at 10:05 PM, Andrew Dunstan <and...@dunslane.net> wrote: ¥> On 04/08/2016 07:15 AM, Christian Ullrich wrote: Michael, none of your patches change this, so how does it ever build on yo

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/08/2016 09:52 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: OK, at this stage it appears to me that if today is the deadline for getting this in for 9.6 then it's going to be missed. It would be unfortunate to go another year without support for that toolchai

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/08/2016 07:15 AM, Christian Ullrich wrote: * Michael Paquier wrote: > On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan <and...@dunslane.net> > wrote: Not out of the woods yet. Attached is what I got from VS2015 on a fresh W10 VM, with Michael's patch 0002 and

Re: [HACKERS] Lower msvc build verbosity level

On 04/08/2016 06:19 AM, Christian Ullrich wrote: Hello, could we perhaps lower the verbosity level of the msvc build (in src/tools/msvc/build.pl) from "detailed" to "normal"? In my experiment, this reduces the size of the build log by 96.4 percent (from 12.5 MiB to 438 KiB), or if the log

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/06/2016 04:50 PM, Andrew Dunstan wrote: On 03/29/2016 09:38 PM, Robert Haas wrote: On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan <and...@dunslane.net> wrote: I am currently travelling, but my intention is to deal with the remaining patches when I'm back home this weekend,

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/29/2016 09:38 PM, Robert Haas wrote: On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan <and...@dunslane.net> wrote: I am currently travelling, but my intention is to deal with the remaining patches when I'm back home this weekend, unless someone beats me to it. Cool. Progress

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 04/05/2016 03:08 PM, Tom Lane wrote: I think there is potentially some use-case for insert-only semantics for an object target, if you want to be sure you're not overwriting data. So I think "throw an error on duplicate key" is marginally better than "reject object target altogether".

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 04/05/2016 12:42 PM, Teodor Sigaev wrote: I've been asked to look at and comment on the SQL API of the feature. I think it's basically sound, although there is one thing that's not clear from the regression tests: what happens if we're inserting into an object and the key already exists?

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 03/31/2016 09:00 AM, Dmitry Dolgov wrote: On 31 March 2016 at 17:31, Vitaly Burovoy > wrote: it is logical to insert new value if "before", then current value, then new value if "after". Oh, I see now. There is a

Re: [HACKERS] raw output from copy

On 04/01/2016 11:42 AM, Daniel Verite wrote: Andrew Dunstan wrote: If someone can make a good case that this is going to be of general use I'll happily go along, but I haven't seen one so far. About COPY FROM with a raw format, for instance just yesterday there was this user

Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

On 03/29/2016 04:56 PM, Andrew Dunstan wrote: On 03/27/2016 10:20 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be

Re: [HACKERS] So, can we stop supporting Windows native now?

On 03/31/2016 06:38 AM, Andres Freund wrote: On 2016-03-31 13:30:58 +0300, Yury Zhuravlev wrote: Craig Ringer wrote: Yeah, you're right. He's not the only one either. I was reacting to the original post, and TBH didn't think it through. The commit logs suggest there's a decent amount of

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

On 03/30/2016 10:21 AM, Tom Lane wrote: Amit Langote writes: On 2016/03/30 15:16, Harshal Dhumal wrote: If we create two different type of constrains (lets say primary key and foreign key) on same table with same name (lets say 'key' ) then its shows same drop

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/29/2016 08:48 PM, Michael Paquier wrote: On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote: On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote: I have machine ready, waiting for animal name and secret. Great! Nice. Thanks. It will

Re: [HACKERS] Alter or rename enum value

On 03/27/2016 10:20 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be rolled back. The only approach I can

Re: [HACKERS] raw output from copy

On 03/28/2016 11:18 PM, Pavel Stehule wrote: Anyway this is certainly not committable as-is, so I'm setting it back to Waiting on Author. But the fact that both libpq and ecpg would need updates makes me question whether we can safely pretend that

Re: [HACKERS] raw output from copy

On 03/28/2016 06:26 PM, Tom Lane wrote: Pavel Stehule writes: [ copy-raw-format-20160227-03.patch ] I looked at this patch. I'm having a hard time accepting that it has a use-case large enough to justify it, and here's the reason: it's a protocol break.

Re: [HACKERS] Alter or rename enum value

On 03/27/2016 12:43 AM, Christophe Pettus wrote: On Mar 26, 2016, at 7:40 AM, Andrew Dunstan <and...@dunslane.net> wrote: It would be nice if we could find a less broad brush approach to dealing with the issue. I don't know how doable this is, but could we use the existing mec

Re: [HACKERS] Alter or rename enum value

On 03/26/2016 10:25 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: We don't have the luxury of being able to redesign this as a green fields development. I'm not actually convinced that we need to do anything. SQL already has a perfectly good mechanism for enf

Re: [HACKERS] Alter or rename enum value

On 03/26/2016 12:35 AM, David G. Johnston wrote: On Friday, March 25, 2016, Andrew Dunstan <and...@dunslane.net <mailto:and...@dunslane.net>> wrote: On 03/25/2016 04:13 AM, Matthias Kurz wrote: Hopefully at the commitfest at least the transaction limitatio

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 03:22 PM, Christophe Pettus wrote: On Mar 25, 2016, at 11:50 AM, Andrew Dunstan <and...@dunslane.net> wrote: I don't believe anyone knows how to do that safely. The core issue, for me, is that not being able to modify enum values in a transaction breaks a very wide v

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/24/2016 12:40 PM, Matt Wilmas wrote: (I notice the btree_gin docs don't mention "numeric," but it works.) Numeric does work - we have regression tests to prove it, do we should fix the docs. But I'm also curious to know why apparently we don't have distance operator support for

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 04:13 AM, Matthias Kurz wrote: Hopefully at the commitfest at least the transaction limitation will/could be tackled - that would help us a lot already. I don't believe anyone knows how to do that safely. Enums pose special problems here exactly because unlike all other

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/25/2016 08:31 AM, Michael Paquier wrote: On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote: On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote: On 24/03/16 17:28, Robert Haas wrote: On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/24/2016 12:40 PM, Matt Wilmas wrote: It would be *really* nice to have this in 9.6. It seems it's simply filling out functionality that should already be there, right? An oversight/bug fix so it works "as advertised?" :-) I think that would be stretching the process a bit far.

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/20/2016 12:02 AM, Michael Paquier wrote: On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan <and...@dunslane.net> wrote: Still to do: the non-perl pieces. The patch to address locales is the sensitive part. The patch from Petr is taking the correct approach though I think that

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/18/2016 09:54 AM, Robert Haas wrote: On Thu, Mar 17, 2016 at 11:21 AM, Andrew Dunstan <and...@dunslane.net> wrote: On 03/17/2016 06:44 AM, Andrew Dunstan wrote: Here is a patch to add enum support to btree_gin and btree_gist. I didn't include distance operations, as I didn't

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 07:40 PM, Michael Paquier wrote: On Wed, Mar 9, 2016 at 1:07 AM, Andrew Dunstan <and...@dunslane.net> wrote: Michael's patch proposes to replace the use of sed to generate probes.h with the perl equivalent everywhere. That has the advantage that we keep to one script to ge

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

On 03/11/2016 06:49 PM, Tom Lane wrote: Anybody know what will happen when passing a uint64 to newSViv()? A perl IV is guaranteed large enough to hold a pointer, if that's any help. But for an unsigned value you might be better off calling newSVuv() cheers

[HACKERS] enums and indexing

Currently we don't have a way to create a GIN index on an array of enums, or to use an enum field in a GIST index, so it can't be used in an exclusion constraint, among other things. I'd like to work on fixing that if possible. Are there any insuperable barriers? If not, what do we need to

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 11:07 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: On 03/09/2016 09:56 AM, Matthias Kurz wrote: Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I don't know of any plans, but it would be a useful

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 09:56 AM, Matthias Kurz wrote: Hi! Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I had a bit of a discussion on the IRC channel and it seems it shouldn't be that hard to implement this. Again, I am talking about renaming

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 11:17 AM, Tom Lane wrote: On the whole, I'd rather that this patch left the non-Windows side alone. OK, that's why I raised the issue. We'll do it that way. As I noted upthread, the sed script has been very stable so the overhead of having to maintain two scripts is pretty

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 10:43 AM, Tom Lane wrote: Andrew Dunstan <and...@dunslane.net> writes: Do we already have a hard dependency on perl for all non-Windows builds? I know it's been discussed but I don't recall. If so, back to what version? I think the policy is we require perl for buildin

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