Re: [HACKERS] [PATCH] Fix search_path default value separator.

2014-08-20 Thread Heikki Linnakangas

On 08/15/2014 04:58 PM, Bruce Momjian wrote:

On Fri, Aug 15, 2014 at 10:40:59PM +0900, Fujii Masao wrote:

Heh.  I'm not particularly averse to changing this, but I guess I
don't see any particular benefit of changing it either.  Either comma
or comma-space is a legal separator, so why worry about it?


This change might cause me to update the existing documents (which
I need to maintain in my company) including the output example of
default search_path. If the change is for the improvement, I'd be
happy to do that, but it seems not.

Also there might be some PostgreSQL extensions which their regression test
shows the default search_path. This patch would make their developers
spend the time to update the test. I'm sure that they are fine with that if
it's for an improvement. But not.


Well, rename GUC often too for clearity, so I don't see adjusting
white-space as something to avoid either.  It is always about short-term
adjustments vs. long-term clarity.


I think this is an improvement, although a really minor one. Although 
Robert  Fujii questioned if this is worth it, I didn't hear anyone 
objecting strongly, so committed.


- Heikki



--
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] [PATCH] Fix search_path default value separator.

2014-08-15 Thread Fujii Masao
On Tue, Jul 15, 2014 at 12:20 AM, Christoph Martin
christoph.r.mar...@gmail.com wrote:
 True. Both variants are legal, and most people won't ever notice. I stumbled
 across this while writing a test case for a transaction helper that
 sets/restores search_path before committing. The test was to simply compare
 the string values of `SHOW search_path;` before `BEGIN TRANSACTION;` and
 after `COMMIT;`.

 It's a non-issue, really, but since there's a patch and I cannot come up
 with a more common use case that would depend on the use of just-comma
 separators in the default value, I'd say it's more of a question of why
 not instead of why, isn't it?


 On 14 July 2014 16:58, Robert Haas robertmh...@gmail.com wrote:

 On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin
 christoph.r.mar...@gmail.com wrote:
  I noticed a minor inconsistency with the search_path separator used in
  the
  default configuration.
 
  The schemas of any search_path set using `SET search_path TO...` are
  separated by ,  (comma, space), while the default value is only
  separated
  by , (comma).
 
  The attached patch against master changes the separator of the default
  value
  to be consistent with the usual comma-space separators, and updates the
  documentation of `SHOW search_path;` accordingly.
 
  This massive three-byte change passes all 144 tests of make check.

 Heh.  I'm not particularly averse to changing this, but I guess I
 don't see any particular benefit of changing it either.  Either comma
 or comma-space is a legal separator, so why worry about it?

This change might cause me to update the existing documents (which
I need to maintain in my company) including the output example of
default search_path. If the change is for the improvement, I'd be
happy to do that, but it seems not.

Also there might be some PostgreSQL extensions which their regression test
shows the default search_path. This patch would make their developers
spend the time to update the test. I'm sure that they are fine with that if
it's for an improvement. But not.

Regards,

-- 
Fujii Masao


-- 
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] [PATCH] Fix search_path default value separator.

2014-08-15 Thread Bruce Momjian
On Fri, Aug 15, 2014 at 10:40:59PM +0900, Fujii Masao wrote:
  Heh.  I'm not particularly averse to changing this, but I guess I
  don't see any particular benefit of changing it either.  Either comma
  or comma-space is a legal separator, so why worry about it?
 
 This change might cause me to update the existing documents (which
 I need to maintain in my company) including the output example of
 default search_path. If the change is for the improvement, I'd be
 happy to do that, but it seems not.
 
 Also there might be some PostgreSQL extensions which their regression test
 shows the default search_path. This patch would make their developers
 spend the time to update the test. I'm sure that they are fine with that if
 it's for an improvement. But not.

Well, rename GUC often too for clearity, so I don't see adjusting
white-space as something to avoid either.  It is always about short-term
adjustments vs. long-term clarity.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + Everyone has their own god. +


-- 
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] [PATCH] Fix search_path default value separator.

2014-07-14 Thread Robert Haas
On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin
christoph.r.mar...@gmail.com wrote:
 I noticed a minor inconsistency with the search_path separator used in the
 default configuration.

 The schemas of any search_path set using `SET search_path TO...` are
 separated by ,  (comma, space), while the default value is only separated
 by , (comma).

 The attached patch against master changes the separator of the default value
 to be consistent with the usual comma-space separators, and updates the
 documentation of `SHOW search_path;` accordingly.

 This massive three-byte change passes all 144 tests of make check.

Heh.  I'm not particularly averse to changing this, but I guess I
don't see any particular benefit of changing it either.  Either comma
or comma-space is a legal separator, so why worry about it?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] [PATCH] Fix search_path default value separator.

2014-07-14 Thread Christoph Martin
True. Both variants are legal, and most people won't ever notice. I
stumbled across this while writing a test case for a transaction helper
that sets/restores search_path before committing. The test was to simply
compare the string values of `SHOW search_path;` before `BEGIN
TRANSACTION;` and after `COMMIT;`.

It's a non-issue, really, but since there's a patch and I cannot come up
with a more common use case that would depend on the use of just-comma
separators in the default value, I'd say it's more of a question of why
not instead of why, isn't it?


On 14 July 2014 16:58, Robert Haas robertmh...@gmail.com wrote:

 On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin
 christoph.r.mar...@gmail.com wrote:
  I noticed a minor inconsistency with the search_path separator used in
 the
  default configuration.
 
  The schemas of any search_path set using `SET search_path TO...` are
  separated by ,  (comma, space), while the default value is only
 separated
  by , (comma).
 
  The attached patch against master changes the separator of the default
 value
  to be consistent with the usual comma-space separators, and updates the
  documentation of `SHOW search_path;` accordingly.
 
  This massive three-byte change passes all 144 tests of make check.

 Heh.  I'm not particularly averse to changing this, but I guess I
 don't see any particular benefit of changing it either.  Either comma
 or comma-space is a legal separator, so why worry about it?

 --
 Robert Haas
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company



[HACKERS] [PATCH] Fix search_path default value separator.

2014-07-11 Thread Christoph Martin
Hi

I noticed a minor inconsistency with the search_path separator used in the
default configuration.

The schemas of any search_path set using `SET search_path TO...` are
separated by ,  (comma, space), while the default value is only separated
by , (comma).

The attached patch against master changes the separator of the default
value to be consistent with the usual comma-space separators, and updates
the documentation of `SHOW search_path;` accordingly.

This massive three-byte change passes all 144 tests of make check.

Regards,

Christoph
From 0f52f107af59f560212bff2bda74e643d63687f0 Mon Sep 17 00:00:00 2001
From: Christoph Martin christoph.r.mar...@gmail.com
Date: Fri, 11 Jul 2014 08:52:39 +0200
Subject: [PATCH] Fix search_path default value separator.

When setting the search_path with `SET search_path TO...`, the schemas
of the resulting search_path as reported by `SHOW search_path` are
separated by a comma followed by a single space. This patch applies the
same format to the default search_path, and updates the documentation
accordingly.
---
 doc/src/sgml/ddl.sgml | 2 +-
 src/backend/utils/misc/guc.c  | 2 +-
 src/backend/utils/misc/postgresql.conf.sample | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 3b7fff4..2273616 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1746,7 +1746,7 @@ SHOW search_path;
 screen
  search_path
 --
- $user,public
+ $user, public
 /screen
 The first element specifies that a schema with the same name as
 the current user is to be searched.  If no such schema exists,
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 3a31a75..a3f1051 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -2915,7 +2915,7 @@ static struct config_string ConfigureNamesString[] =
 			GUC_LIST_INPUT | GUC_LIST_QUOTE
 		},
 		namespace_search_path,
-		\$user\,public,
+		\$user\, public,
 		check_search_path, assign_search_path, NULL
 	},
 
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 3f3e706..df98b02 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -499,7 +499,7 @@
 
 # - Statement Behavior -
 
-#search_path = '$user,public'		# schema names
+#search_path = '$user, public'	# schema names
 #default_tablespace = ''		# a tablespace name, '' uses the default
 #temp_tablespaces = ''			# a list of tablespace names, '' uses
 	# only default tablespace
-- 
2.0.1


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers