Re: Doc patch, index search_path where it's used to secure functions - Mailing list pgsql-hackers

From Karl O. Pinc
Subject Re: Doc patch, index search_path where it's used to secure functions
Date
Msg-id 1352874080.4647.0@mofo
Whole thread Raw
In response to Re: Doc patch, index search_path where it's used to secure functions  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Doc patch, index search_path where it's used to secure functions
List pgsql-hackers
On 11/13/2012 08:46:19 PM, Peter Eisentraut wrote:
>
> Well, I'm not sure.  We currently have three index entries on the
> topic:
>
> search path
> search_path
> search_path configuration parameter
>
> I think I'd put them all under search_path.

Ok.

I think you are right that they need to all be
under one index entry.

It might make sense to have a "search term"
entry that says "see search_term", but since
the two entries would be right next to each
other in the index this seems overkill.

I'm going to send this in as a single patch
that fixes all the search path related
index entries:

  search_path-index.patch

(replaces search_path-normalize.patch
  and search_path-securing_v2.patch)

This new patch also changes the
search path index in doc/src/sgml/func.sgml.
Perhaps I just don't understand the logic
in the indexing in that file but the
search path index there seems to point to the
entire file/nowhere useful.  Since there are 2 places
in the file that are concerned with
search path I've removed the "global"
index into the file and added new
index entries.  This also moved the
"schema, current" index target.
(Since that too involves search path.)

I've also added a <seealso> entry to "schema, current"
to the top-level "search_path" index entry.

If you want this broken up into smaller
patches let me know.

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Next
From: Amit Kapila
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL