Re: [HACKERS] [PATCH] Fix search_path default value separator.
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.
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 http://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.
On Tue, Jul 15, 2014 at 12:20 AM, Christoph Martin 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 wrote: >> >> On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin >> 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.
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 wrote: > On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin > 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 >
Re: [HACKERS] [PATCH] Fix search_path default value separator.
On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin 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
[HACKERS] [PATCH] Fix search_path default value separator.
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 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; search_path -- - "$user",public + "$user", public 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
