Documentation fix for CREATE FUNCTION
I just noticed that the documentation for CREATE FUNCTION still mentions
that the temporary namespace is searched for functions even though that
has been removed with commit aa27977.
Attached is a patch to fix that.
Yours,
Laurenz Albe
Attachments:
0001-Fix-mention-of-pg_temp-in-CREATE-FUNCTION-documentat.patchapplication/octet-stream; name=0001-Fix-mention-of-pg_temp-in-CREATE-FUNCTION-documentat.patchDownload+5-8
Albe Laurenz <laurenz.albe@wien.gv.at> writes:
I just noticed that the documentation for CREATE FUNCTION still mentions
that the temporary namespace is searched for functions even though that
has been removed with commit aa27977.
The example you propose to correct was introduced by that same commit,
which should make you think twice about whether it really was invalidated
by that commit.
I believe the reason for forcing pg_temp to the back of the path is to
prevent unqualified table names from being captured by pg_temp entries.
This risk exists despite the rule against searching pg_temp for functions
or operators. A maliciously named temp table could at least prevent
a security definer function from doing what it was supposed to, and
could probably hijack control entirely via triggers or rules.
Possibly the documentation should be more explicit about why this is
being done, but the example code is good as-is.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Albe Laurenz <laurenz.albe@wien.gv.at> writes:
I just noticed that the documentation for CREATE FUNCTION still mentions
that the temporary namespace is searched for functions even though that
has been removed with commit aa27977.The example you propose to correct was introduced by that same commit,
which should make you think twice about whether it really was invalidated
by that commit.
Yes, I wondered about that.
I believe the reason for forcing pg_temp to the back of the path is to
prevent unqualified table names from being captured by pg_temp entries.
This risk exists despite the rule against searching pg_temp for functions
or operators. A maliciously named temp table could at least prevent
a security definer function from doing what it was supposed to, and
could probably hijack control entirely via triggers or rules.Possibly the documentation should be more explicit about why this is
being done, but the example code is good as-is.
Maybe something like the attached would keep people like me from
misunderstanding this.
Yours,
Laurenz Albe
Attachments:
0001-Improve-example-in-CREATE-FUNCTION-documentation.patchapplication/octet-stream; name=0001-Improve-example-in-CREATE-FUNCTION-documentation.patchDownload+4-2
Albe Laurenz <laurenz.albe@wien.gv.at> writes:
Tom Lane wrote:
I believe the reason for forcing pg_temp to the back of the path is to
prevent unqualified table names from being captured by pg_temp entries.
This risk exists despite the rule against searching pg_temp for functions
or operators. A maliciously named temp table could at least prevent
a security definer function from doing what it was supposed to, and
could probably hijack control entirely via triggers or rules.Possibly the documentation should be more explicit about why this is
being done, but the example code is good as-is.
Maybe something like the attached would keep people like me from
misunderstanding this.
I rewrote this a bit and pushed it. Thanks for the suggestion!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers