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 abou
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 caus
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
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
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 onl
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