Re: Doc patch, normalize search_path in index

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Karl O(dot) Pinc" <kop(at)meme(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Doc patch, normalize search_path in index
Date: 2013-01-25 18:59:41
Message-ID: 20130125185941.GJ6848@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
> On 1/25/13 12:50 PM, Bruce Momjian wrote:
> > On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
> >> Hi,
> >>
> >> The attached patch (against git head)
> >> normalizes "search_path" as the thing indexed
> >> and uses a secondary index term to distinguish
> >> the configuration parameter from the run-time
> >> setting.
> >>
> >> "search path" the concept remains distinguished
> >> in the index from "search_path" the setting/config param.
> >> It's hard to say whether it's useful to make this
> >> distinction. From a practical perspective it's easy
> >> for the eye to stop scanning when the indent
> >> level changes and so fail to notice that both
> >> "search path" and "search_path" are index
> >> entries. At least the index is a
> >> lot more tidy than before.
> >
> > I have applied a modified version of your patch that creates separate
> > secondary index references for search_path.
>
> This matter was already closed:
> https://commitfest.postgresql.org/action/patch_view?id=949
>
> It looks like your patch reverts part of that.

Uh, I am confused because the patch at:

https://commitfest.postgresql.org/action/patch_view?id=950
http://www.postgresql.org/message-id/1352874080.4647.0@mofo

shows "configuration parameter" being moved to <secondary>, though this
commit:

http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=a301eb99c9537186f7dd46ba418e84d755227a94

shows it not as secondary. Would you please suggest a patch or patch
it? Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-01-25 19:02:39 Re: Question regarding Sync message and unnamed portal
Previous Message Stephen Frost 2013-01-25 18:54:33 Re: LATERAL, UNNEST and spec compliance