Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/12/2016 06:51 PM, Heikki Linnakangas wrote: Changes since last version: * Added more error checks to the my_BIO_s_socket() function. Check for NULL result from malloc(). Check the return code of BIO_meth_set_*() functions; looking at OpenSSL sources, they always succeed, but all the

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/05/2016 02:23 AM, Tom Lane wrote: Judging by the number of people who have popped up recently with their own OpenSSL 1.1 patches, I think there is going to be a lot of demand for back-patching some sort of 1.1 support into our back branches. All this talk of refactoring does not sound

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

/message-id/561274f1.1030...@iki.fi). I dropped the ball back then, but I think I'll go ahead and do that now, once we get these other OpenSSL changes in. Nice! Andreas >From 0afeb5e075028339f28c2c2d7b407c1bcc85c4be Mon Sep 17 00:00:00 2001 From: Andreas Karlsson <andr...@proxel.se> Dat

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 08/31/2016 11:34 PM, Peter Geoghegan wrote: On Sun, Nov 22, 2015 at 7:29 PM, Andreas Karlsson <andr...@proxel.se> wrote: Sorry for dropping this patch, but now I have started looking at it again. Any chance of picking this up again soon, Andreas? I think it's an important project. I

Re: [HACKERS] Improve BEGIN tab completion

On 09/01/2016 11:28 PM, Kevin Grittner wrote: On Wed, May 18, 2016 at 8:59 AM, Andreas Karlsson <andr...@proxel.se> wrote: I noticed that the tab completion was not aware of that TRANSACTION/WORK is optional in BEGIN, and that we do not complete [NOT] DEFERRABLE. While fixing it

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/26/2016 11:31 AM, Heikki Linnakangas wrote: On 07/05/2016 04:46 PM, Andreas Karlsson wrote: @@ -280,8 +287,9 @@ px_find_digest(const char *name, PX_MD **res) digest = px_alloc(sizeof(*digest)); digest->algo = md; -EVP_MD_CTX_init(>ctx); -if (EVP_DigestInit_e

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/29/2016 07:22 PM, Heikki Linnakangas wrote: Pushed with some small doc fixes, thanks Andreas! I'll continue reviewing the rest of the patches. Thanks! Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/26/2016 07:04 PM, Heikki Linnakangas wrote: On 08/26/2016 07:44 PM, Tom Lane wrote: Peter Eisentraut writes: On 8/26/16 5:31 AM, Heikki Linnakangas wrote: I think now would be a good time to drop support for OpenSSL versions older than 0.9.8. OpenSSL

Re: [HACKERS] fixes for the Danish locale

On 07/22/2016 03:59 AM, Jeff Janes wrote: On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane wrote: I see that the core tests fall over in Turkish still :-( Turkish has never passed (at least back to 9.0). It looks like it is in the stemming functions. I don't understand why, I

Re: [HACKERS] bug in citext's upgrade script for parallel aggregates

On 07/09/2016 05:42 AM, David Rowley wrote: On 30 June 2016 at 03:49, Robert Haas <robertmh...@gmail.com> wrote: On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson <andr...@proxel.se> wrote: On 06/24/2016 01:31 PM, David Rowley wrote: Seems there's a small error in the up

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 07/05/2016 11:13 AM, Victor Wagner wrote: On Fri, 1 Jul 2016 02:27:03 +0200 Andreas Karlsson <andr...@proxel.se> wrote: 0003-Remove-OpenSSL-1.1-deprecation-warnings.patch Silence all warnings. This commit changes more things and is not necessary for getting PostgreSQL to build again

Re: [HACKERS] to_date_valid()

On 07/04/2016 10:55 PM, Pavel Stehule wrote: 2016-07-04 22:15 GMT+02:00 Andreas Karlsson <andr...@proxel.se <mailto:andr...@proxel.se>>: I do not see a clear conclusion in the linked threads. For example Bruce calls it a bug in one of the emails (https://www.postgresql

Re: [HACKERS] to_date_valid()

On 07/03/2016 12:36 PM, Andreas 'ads' Scherbaum wrote: On 03.07.2016 07:05, Jaime Casanova wrote: Shouldn't we fix this instead? Sounds like a bug to me. We don't usually want to be bug compatible so it doesn't matter if we break something. There are previous discussions about such a change,

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

On 07/01/2016 07:31 PM, Andres Freund wrote: Yeah, but since when has the SQL standard adopted any existing implementation's spelling of a feature? It seems to be politically impossible. Especially if nobody really lobbies on part of postgresql. Has any of the major PostgreSQL companies

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 07/02/2016 02:45 AM, Andreas Karlsson wrote: On 07/02/2016 02:28 AM, Alvaro Herrera wrote: Generally, version number tests sprinkled all over the place are not terribly nice. I think it would be better to get configure to define a symbol like HAVE_BIO_METH_NEW. Not sure about the other

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 07/02/2016 02:28 AM, Alvaro Herrera wrote: static BIO_METHOD * my_BIO_s_socket(void) { - if (!my_bio_initialized) + if (!my_bio_methods) { - memcpy(_bio_methods, BIO_s_socket(), sizeof(BIO_METHOD)); - my_bio_methods.bread = my_sock_read; -

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

reas >From 59cb028a38c18cb2f8fff077d355a8a26ecce641 Mon Sep 17 00:00:00 2001 From: Andreas Karlsson <andr...@proxel.se> Date: Tue, 28 Jun 2016 05:55:03 +0200 Subject: [PATCH 1/4] Fixes for compiling with OpenSSL 1.1 - Check for SSL_new now that SSL_library_init is a macro - Do not access struct members dir

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

the library and 2) no longer uses the locking callback. - Silences deprecation warning when generating DH parameters. Andreas >From 16bda89ea853d7ee160e049a300771b967f966ff Mon Sep 17 00:00:00 2001 From: Andreas Karlsson <andr...@proxel.se> Date: Tue, 28 Jun 2016 05:55:03 +0200 Subject: [

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 06/27/2016 08:12 PM, Christoph Berg wrote: Re: Andreas Karlsson 2016-06-27 <8a0a5959-0b83-3dc8-d9e7-66ce8c1c5...@proxel.se> The errors you report make it sound like they broke API compatibility wholesale. Was that really their intent? If so, where are the changes documented? I do n

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 06/27/2016 05:24 PM, Tom Lane wrote: Christoph Berg writes: as reported by Debian's OpenSSL maintainers, PostgreSQL is failing to build against a snapshot of the upcoming 1.1.0 version. The errors you report make it sound like they broke API compatibility wholesale. Was

Re: [HACKERS] bug in citext's upgrade script for parallel aggregates

On 06/24/2016 01:31 PM, David Rowley wrote: Seems there's a small error in the upgrade script for citext for 1.1 to 1.2 which will cause min(citext) not to be parallel enabled. max(citext)'s combinefunc is first set incorrectly, but then updated to the correct value. I assume it was meant to

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/17/2016 09:11 PM, Robert Haas wrote: I was kind of hoping you'd have a new version of this posted already. beta2 is wrapping on Monday, and I'm inclined to shelve anything that isn't done by then for the next release. And I don't really plan to work much this weekend. Here they are.

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/14/2016 09:55 PM, Robert Haas wrote: On Tue, Jun 14, 2016 at 1:51 PM, Robert Haas <robertmh...@gmail.com> wrote: On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson <andr...@proxel.se> wrote: I have rebased all my patches on the current master now (and skipped the extensions

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/14/2016 07:51 PM, Robert Haas wrote: On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson <andr...@proxel.se> wrote: I have rebased all my patches on the current master now (and skipped the extensions I previously listed). Thanks, this is really helpful. It was starting to ge

[HACKERS] Use of CREATE OR REPLACE in bloom--1.0.sql

Hi, I do not think that extension SQL scripts should be using CREATE OR REPLACE FUNCTION like bloom--1.0.sql currently does. I suspect that this might just be a typo. I have attached the tiny patch which fixes this. Andreas diff --git a/contrib/bloom/bloom--1.0.sql

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:54 PM, Andreas Karlsson wrote: On 06/07/2016 05:44 PM, Robert Haas wrote: cube: I think we need a new extension version. hstore: Does not apply for me. intarray: Does not apply for me. Those three and ltree, pg_trgm, and seg depend on my patch with fixes for the GiST/GIN

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/10/2016 01:44 PM, Andreas Karlsson wrote: I have attached a patch which adds the shcema, plus an updated patch for tseach2. Forgot adding schema to the tables. Here are new versions. Andreas parallel-contrib-v4-tsearch2.patch.gz Description: application/gzip diff --git a/contrib

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/09/2016 10:48 PM, Tom Lane wrote: Robert Haas writes: On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: Yes, let's fix it. This will also take care of the questions about whether the GIN/GIST opclass tweaks I made a few months ago require

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:44 PM, Robert Haas wrote: adminpack: Doesn't seem useful. The case I imagined was if someone would use these functions on the result from a slow CTE and would want the CTE to be executed in parallel. I have no idea if that is a realistic case, but I rarely use adminpack in

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:44 PM, Robert Haas wrote: cube: I think we need a new extension version. hstore: Does not apply for me. intarray: Does not apply for me. Those three and ltree, pg_trgm, and seg depend on my patch with fixes for the GiST/GIN function signatures in

Re: [HACKERS] slower connect from hostnossl clients

On 06/07/2016 12:18 PM, Magnus Hagander wrote: > Intersting. Can you check with a network trace that it actually turns > off ssl, so nothing is broken there? > > One thing that could be taking the time is an extra roundtrip -- e.g. it > tries to connect with ssl fails and retries without. A

Re: [HACKERS] Parallel safety tagging of extension functions

Hi, Here is the patch split into many small patches as you suggested. The current patches are based on top of the patch which fixes the signatures for gin and gist functions. These patches only touch functions which never should be called directly, so they are fine to skip. I decided to

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/02/2016 01:41 AM, Michael Paquier wrote: > On Thu, Jun 2, 2016 at 7:36 AM, Andreas Karlsson <andr...@proxel.se> wrote: >> Looked at this quickly and I do not think adding it would be what I consider >> a small patch since we would essentially need to copy the valid

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:32 AM, Tom Lane wrote: Andreas Karlsson <andr...@proxel.se> writes: On 05/25/2016 02:41 AM, Robert Haas wrote: I'd rather extend see us ALTER AGGREGATE to do this. Wouldn't that prevent this from going into 9.6? I do not think changing ALTER AGGREGATE is 9.6 mat

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/01/2016 05:15 PM, Tom Lane wrote: Andreas Karlsson <andr...@proxel.se> writes: On 06/01/2016 04:44 PM, Tom Lane wrote: I don't understand why you think you need the CREATE OR REPLACE FUNCTION commands? We only need to change proargtypes, and the updates did that. The catcache ca

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/01/2016 04:44 PM, Tom Lane wrote: Andreas Karlsson <andr...@proxel.se> writes: It is the least ugly of all the ugly solutions I could think of. I have attached a patch which fixes the signatures using this method. I use CREATE OR REPLACE FUNCTION to update to catcache. What do you

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/31/2016 06:47 PM, Tom Lane wrote: Given that, your original approach of manually updating proargtypes in the existing pg_proc row for the functions may be the best way. Anything else is going to be more complicated and ultimately will still require at least one direct catalog update. It

Re: [HACKERS] Binary I/O for isn extension

Hi, Thanks for the patch, you can add it to our commitfest app so it gets reviewed in the next commitfest. https://commitfest.postgresql.org/ A suggestion to make it easier for your patch to be accepted: When adding new functions to an extension you need to bump the version of the

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 04:06 AM, Tom Lane wrote: Andreas Karlsson <andr...@proxel.se> writes: On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The % delimiter character is not only used at the end of the IPV6 address, from the RFC document, it is possible as follows also. fe80::%2/64 we need to

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The following is the content of IPV6 representation from RFC 4007 The following addresses fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:37 AM, Tom Lane wrote: Andreas Karlsson <andr...@proxel.se> writes: Ok, then I can avoid touching all functions which are only called by operator classes, tsearch, pls, fdws, etc. Which also means that there is no need to care about Tom's changes to the signatures

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:09 AM, Robert Haas wrote: On Tue, May 24, 2016 at 8:41 PM, Robert Haas wrote: - Do you think we should add PARALLEL UNSAFE to the functions which we know are unsafe to make it obvious that it is intentional? That seems likely unnecessary churn from

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 02:41 AM, Robert Haas wrote: On Thu, May 19, 2016 at 5:50 PM, Andreas Karlsson <andr...@proxel.se> wrote: - How should we modify the aggregate functions when upgrading extensions? ALTER AGGREGATE cannot change COMBINEFUNC or PARALLEL. My current patch updates the system ca

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 02:34 AM, Robert Haas wrote: On Fri, May 20, 2016 at 11:45 PM, Michael Paquier wrote: Sounds to me that this is part of the cleanup of a 9.6 feature and should be in that release. Yes, I agree. By the way, the patch completely ignores the fact that

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/21/2016 11:45 AM, Tom Lane wrote: Yes, let's fix it. This will also take care of the questions about whether the GIN/GIST opclass tweaks I made a few months ago require module version bumps. Do you have any idea what the best way to add these tweaks to the upgrade scripts would be?

Re: [HACKERS] Parallel safety tagging of extension functions

Another question which I thought of is what we should do with functions like pg_file_write() in adminpack. While it is perfectly fine to modify files from the parallel workers, a user could get race conditions if he tries to modify the same file multiple times. Is this a kind of problem the

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/20/2016 11:45 PM, Michael Paquier wrote: Yes, I agree. By the way, the patch completely ignores the fact that some of the modules already had a version bump in the 9.6 development cycle, like pageinpect. You don't need to create a new version script in such cases. I assumed this was too

[HACKERS] Parallel safety tagging of extension functions

Hi, I have gone through all our extensions and tried to tag all functions correctly according to their parallel safety. I also did the same for the aggregate functions in a second patch, and for min(citext)/max(citext) set a COMBINEFUNC. The changes for the functions is attached as one

[HACKERS] Improve BEGIN tab completion

Hi, I noticed that the tab completion was not aware of that TRANSACTION/WORK is optional in BEGIN, and that we do not complete [NOT] DEFERRABLE. While fixing it I also improved the completion support for SET SESSION slightly. Andreas diff --git a/src/bin/psql/tab-complete.c

Re: [HACKERS] Accidentally parallel unsafe functions

On 05/03/2016 08:45 PM, Robert Haas wrote: Committed all of this except for the bit about pg_start_backup, for which I committed a separate fix. Thanks, and really good that you spotted the pg_start_backup() issue. Andreas -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Accidentally parallel unsafe functions

On 04/30/2016 01:19 AM, Tom Lane wrote: Alvaro Herrera writes: Surely CREATE OR REPLACE should keep whatever the flag was, rather than ovewrite it with a bogus value if not specified? In other words IMO the CREATE OR REPLACE code needs changing, not system_views.sql.

[HACKERS] Accidentally parallel unsafe functions

to ignore that one if you like. Affected functions: - json_populate_record() - json_populate_recordset() - jsonb_insert() - jsonb_set() - make_interval() - parse_ident() - Loads of conversion functions Andreas commit 9afcc5f1ed22be18d69dc0b70a0f057a023cc5ec Author: Andreas Karlsson <a

Re: [HACKERS] Can we improve this error message?

On 04/17/2016 09:28 PM, Bill Moran wrote: If you have a single line in the pg_hba.conf: hostssl all all 0.0.0.0/0 md5 Attempting to log in with an incorrect password results in an error message about there not being a pg_hba.conf entry for the user. Reading carefully, the error message states

Re: [HACKERS] Wire protocol compression

On 04/21/2016 03:04 PM, Aleksander Alekseev wrote: I guess since the usual answer for compression was "use what SSL provides you for free", it's rather unlikely that someone bothered to make a proxy just for that purpose, and really, a proxy is just another moving part in your setup: not

Re: [HACKERS] Refactor pg_dump as a library?

On 04/14/2016 07:28 PM, David Steele wrote: As far as I know pg_dump share locks everything before it starts so there shouldn't be issues with concurrent DDL. Try creating a new inherited table with FKs, etc. during a pg_dump and you'll see lots of fun lock waits. I am pretty sure that it

Re: [HACKERS] Refactor pg_dump as a library?

On 04/14/2016 12:22 PM, Craig Ringer wrote: I'd find a pg_get_tabledef(...) built-in function more interesting for this particular purpose than pg_dump as a library would be. We already have pg_get_viewdef(...), pg_get_functiondef(...) etc. I am personally not a fan of the pg_get_Xdef()

Re: [HACKERS] 2016-03 Commitfest

On 04/11/2016 01:35 PM, David Steele wrote: I've marked this committed so the 2016-03 CF is now complete! Thanks to you and everyone else involved in running this CF. You did an excellent job. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] NOT EXIST for PREPARE

On 03/24/2016 11:21 PM, Merlin Moncure wrote: Personally I think the right solution would be to add support for prepared statements in pgbouncer, and have pgbouncer run PREPARE as necessary, either after opening a new connection to the database or at the first use of a given prepared statement

Re: [HACKERS] NOT EXIST for PREPARE

On 03/23/2016 09:10 PM, Stephen Frost wrote: * Merlin Moncure (mmonc...@gmail.com) wrote: No one is arguing that that you should send it any every time (at least -- I hope not). I'm not sure I follow how you can avoid that though? pgbouncer in transaction pooling mode may let a particular

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On 03/23/2016 02:13 PM, Alvaro Herrera wrote: Andreas Karlsson escribió: On 03/23/2016 01:55 PM, Eduardo Morras wrote: Benefits: Dynamic multihoming, modifiable at run time, don't need aggregate links at OS level or shutdown servers/clients for a hardware or topology network change. Message

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On 03/23/2016 01:55 PM, Eduardo Morras wrote: Benefits: Dynamic multihoming, modifiable at run time, don't need aggregate links at OS level or shutdown servers/clients for a hardware or topology network change. Message oriented connection. Message reliability. Inmune to SYN floods that affect

Re: [HACKERS] 2016-03 Commitfest

Hi, The COPY RAW patch seems to have two entries in the commitfest. https://commitfest.postgresql.org/9/223/ and https://commitfest.postgresql.org/9/547/ Are those about the same patch? Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] POC, WIP: OR-clause support for indexes

I gave this patch a quick spin and noticed a strange query plan. CREATE TABLE test (a int, b int, c int); CREATE INDEX ON test USING gin (a, b, c); INSERT INTO test SELECT i % 7, i % 9, i % 11 FROM generate_series(1, 100) i; EXPLAIN ANALYZE SELECT * FROM test WHERE (a = 3 OR b = 5) AND c =

Re: [HACKERS] syslog configurable line splitting behavior

On 03/16/2016 03:50 AM, Peter Eisentraut wrote: On 3/8/16 9:12 PM, Andreas Karlsson wrote: I have one nitpick: why is one of the variables "true" while the other is "on" in the example? I think both should be "on". #syslog_sequence_numbers = true #syslog_spli

Re: [HACKERS] NOT LIKE index support

On 03/15/2016 11:01 PM, Arjen Nienhuis wrote: I noticed index support for NOT LIKE is missing. Is there a special reason for that, or would a patch be accepted? A use case would be: ... WHERE url NOT LIKE 'http%' Or ... WHERE path NOT LIKE '/%' My guess is the lack of many compelling use

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On 03/08/2016 01:24 AM, Regina Obe wrote: On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe > wrote: I think the answer to this question is NO, but thought I'd ask. A lot of folks in PostGIS land are suffering from restore issues, materialized view issues etc. because we have functions

Re: [HACKERS] syslog configurable line splitting behavior

On 03/09/2016 03:20 AM, Peter Eisentraut wrote: On 3/8/16 9:12 PM, Andreas Karlsson wrote: As someone who uses syslog for my servers I find both of these GUCs useful, especially when used in combination, and I do not think a compile time option like suggest by Alexander would be suitable

Re: [HACKERS] syslog configurable line splitting behavior

On 02/27/2016 04:49 AM, Peter Eisentraut wrote: So I propose the two attached patches that introduce new configuration Boolean parameters syslog_sequence_numbers and syslog_split_lines that can toggle these behaviors. As someone who uses syslog for my servers I find both of these GUCs useful,

Re: [HACKERS] Submit Pull Request

On 03/03/2016 12:11 PM, Maton, Brett wrote: How do I push a branch to git.postgresql.org/git/pgrpms.git ? I would email pgsql-pkg-...@postgresql.org, as mentioned at http://yum.postgresql.org/contact.php, with questions about how to contribute to

Re: [HACKERS] UNIQUE capability to hash indexes

On 02/04/2016 11:34 PM, Tom Lane wrote: Alvaro Herrera writes: This is really strange though. Surely adding WAL-logging is not an enormous task anymore ... I mean, we're undertaking far larger efforts now, the WAL logging code is simpler than before, and we even have

Re: [HACKERS] Generalizing SortSupport for text to work with char(n), bytea, and alternative opclasses

Hi, I have reviewed this now and I think this is a useful addition even though these indexes are less common. Consistent behavior is worth a lot in my mind and this patch is reasonably small. The patch no longer applies due to 1) oid collisions and 2) a trivial conflict. When I fixed those

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/23/2016 01:03 PM, Peter Eisentraut wrote: committed Thanks! Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] COPY (... tab completion

On 01/19/2016 07:55 AM, Michael Paquier wrote: +/* If we have COPY BINARY, compelete with list of tables */ s/compelete/complete Fixed. +else if (TailMatches2("COPY|\\copy", "(")) +COMPLETE_WITH_LIST7("SELECT", "TABLE", "VALUES", "INSERT", "UPDATE", "DELETE", "WITH"); This

Re: [HACKERS] COPY (... tab completion

theses is documented to be: SELECT, VALUES, INSERT, UPDATE or DELETE; and actually TABLE should also work. Your list doesn't include all of those. So please adjust that. Fixed. And TABLE works too. Andreas commit 3b7a808e710e613f81abd0207847a3378ec3192c Author: Andreas Karlsson <andr

Re: [HACKERS] COPY (... tab completion

On 01/19/2016 01:57 AM, Andreas Karlsson wrote: Thanks for the review. A new version is attached. Whops, attached the wrong file. Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index ad8a580..bc80ed0 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/11/2016 02:39 AM, Peter Eisentraut wrote: The second part is not necessary, because there is already code that completes FDW names after "FOREIGN DATA WRAPPER". So this already works. Good spot, thanks. I have no idea why I did not think it worked. Maybe it just did not work in 9.2 and

Re: [HACKERS] COPY (... tab completion

Hi, I have an updated patch which uses Matches() rather than TailMatches(). Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index b5117d4..158b913 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -1934,12 +1934,19 @@

Re: [HACKERS] Making tab-complete.c easier to maintain

On 01/06/2016 01:13 AM, Michael Paquier wrote: On Wed, Jan 6, 2016 at 2:03 AM, Tom Lane wrote: I've pushed the second patch now. I made a few adjustments --- notably, I didn't like the way you'd implemented '*' wildcards, because they wouldn't have behaved very sanely in

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/04/2016 07:26 AM, Michael Paquier wrote: You may want to use Matches() instead of TailMatches() for performance reasons. Here is an updated version which uses Matches(). Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index 4d2bee1..34dabc5 100644 ---

Re: [HACKERS] \x auto and EXPLAIN

On 01/03/2016 06:43 PM, Tom Lane wrote: I see two ways to fix this. 1) Never use expanded display for the case where there is only one column. There seems to me like there is little value in using expanded display for when you only have one column, but I may be missing some use case here.

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/04/2016 07:26 AM, Michael Paquier wrote: You may want to use Matches() instead of TailMatches() for performance reasons. Probably, but if so should we not also change the surrounding rules to also use Matches()? I imitated the surrounding code to keep code consistency and avoid errors.

[HACKERS] \x auto and EXPLAIN

Hi, psql's "\x auto" is a nice feature, but it is made much less useful in my opinion due to the expanded output format making query plans unreadable (and query plans often end up using expanded display due to their width). I think we should never use the expanded format for EXPLAIN output

[HACKERS] Improved tab completion for FDW DDL

Hi, Here is a patch which adds the below missing tab completions for the FDW DDL commands. I noticed these were missing while playing around with FDWs a while ago. "ALTER SERVER " with "RENAME TO" "CREATE SERVER FOREIGN DATA WRAPPER" with fdw name "CREATE|ALTER USER MAPPING FOR SERVER "

[HACKERS] COPY (... tab completion

Hi, Here is a patch which adds tab completion for COPY with a query. Currently there is only completion for COPY with a relation. Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index 98884eb..98023ca 100644 --- a/src/bin/psql/tab-complete.c +++

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On 12/14/2015 01:57 PM, Merlin Moncure wrote: This may be moot; some testing demonstrated that libedit was not impacted so it really comes down to having the right readline api call available. Looking at the code ISTM that libedit resets the terminal on every prompt. Did you manage to figure

[HACKERS] Check for interrupts in bf and xdes crypt()

Hi, Here is a patch which makes it possible to cancel a query which runs the crypt() function with the bf or xdes hashing algorithm, e.g. crypt('foo', gen_salt('bf', 13)). The md5 algorithm does not run for multiple rounds so there is no reason to patch it. I noticed this problem when I

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

Hi, I have reviewed this patch and it still applies to master, compiles and passes the test suite. I like the goal of the patch, making use of the already existing abbreviation machinery in more cases is something we should do and the patch itself looks clean. I can also confirm the

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 08/26/2015 07:46 AM, Michael Paquier wrote: On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier wrote: On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote: [...] So I think the way to move this forward is to investigate how to hold the SSL config

Re: [HACKERS] Commitfest remaining "Needs Review" items

On 08/31/2015 03:34 PM, Alexander Korotkov wrote: +1 for making these dates more explicit Yeah, I think being explicit would make life easier for newcomers. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 08/26/2015 03:57 AM, Tom Lane wrote: Is it unreasonable of me to ask for the Windows behavior to be fixed at the same time? I dunno. It's perhaps less broken than the Unix behavior, but that doesn't make it desirable. OTOH it might be a significantly larger patch, and I confess I'm not

Re: [HACKERS] Commitfest remaining Needs Review items

with the patch. I do not really see what more I can do here other than resubmit it to the next CF which I feel would be poor etiquette by me. If you have the time I to spare I would be very grateful if you could clarify what work you think needs to be done. -- Andreas Karlsson -- Sent via

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

On 07/15/2015 09:30 PM, Robert Haas wrote: On Tue, Jul 14, 2015 at 5:57 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 7/7/15 7:07 AM, Andres Freund wrote: On 2015-07-03 18:03:58 -0400, Tom Lane wrote: I have just looked through this thread, and TBH I think we should reject this patch

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 07/29/2015 03:24 AM, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: I don't have a problem with rebuilding the SSL context on every reload cycle. We already do a lot of extra reloading every time, so a bit more shouldn't hurt. But I'm not so sure whether we should do that in the

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On 07/30/2015 04:48 AM, Michael Paquier wrote: On Thu, Jul 30, 2015 at 5:54 AM, Andreas Karlsson andr...@proxel.se wrote: What I do not like though is how the path src/test/tables_fk/t/ tells us nothing about what features are of PostgreSQL are tested here. For this I personally prefer

Re: [HACKERS] Proposal: backend niceness / session_priority

On 07/31/2015 12:18 AM, Jim Nasby wrote: This has been proposed before, and rejected before, and I'm not seeing anything particularly new here. Without a credible mechanism for throttling I/O, nice alone does not seem very promising. Some OSes respect nice when it comes to IO scheduling, so

Re: [HACKERS] Improving test coverage of extensions with pg_dump

I have reviewed this patch and it compiles runs and the new test case passes. The code is also clean and the test seems like a useful regression test. What I do not like though is how the path src/test/tables_fk/t/ tells us nothing about what features are of PostgreSQL are tested here. For

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 07/23/2015 07:19 AM, Michael Paquier wrote: On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson andr...@proxel.se wrote: On 07/02/2015 06:13 PM, Peter Eisentraut wrote: I think this would be a useful feature, and the implementation looks sound. But I don't like how the reload is organized

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 07/02/2015 06:13 PM, Peter Eisentraut wrote: I think this would be a useful feature, and the implementation looks sound. But I don't like how the reload is organized. Reinitializing the context in the sighup handler, aside from questions about how much work one should do in a signal

Re: [HACKERS] PoC: Partial sort

On 09/15/2014 01:58 PM, Alexander Korotkov wrote: On Sun, Sep 14, 2014 at 9:32 AM, Peter Geoghegan p...@heroku.com mailto:p...@heroku.com wrote: I think we might be better off if a tuplesort function was called shortly after tuplesort_begin_heap() is called. How top-n heap sorts

Re: [HACKERS] Fix autoconf deprecation warnings

I have attached new versions which apply on the current master. Andreas From a4a4970d37b710449ccd57a8b4d896a3c004b62a Mon Sep 17 00:00:00 2001 From: Andreas Karlsson andr...@proxel.se Date: Thu, 12 Feb 2015 23:55:01 +0100 Subject: [PATCH 1/4] Replace obsolete macros AC_TRY_* with AC_*_IFELSE

<    1   2   3   4   >