database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-02 09:02:37 +03:00
Code Activity

Document security implications of qualified names.

Browse Source 
Commit 5770172cb0 documented secure schema
usage, and that advice suffices for using unqualified names securely.
Document, in typeconv-func primarily, the additional issues that arise
with qualified names.  Back-patch to 9.3 (all supported versions).

Reviewed by Jonathan S. Katz.

Discussion: https://postgr.es/m/20180721012446.GA1840594@rfd.leadboat.com
This commit is contained in:
Noah Misch
2018-07-28 20:08:01 -07:00
parent 6bf0bc842b
commit e09144e6ce
6 changed files with 147 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/backend/utils/adt/ruleutils.c
View File

@ -10761,16 +10761,11 @@ generate_function_name(Oid funcid, int nargs, List *argnames, Oid *argtypes,
* Determine whether VARIADIC should be printed. We must do this first
* since it affects the lookup rules in func_get_detail().
*
* Currently, we always print VARIADIC if the function has a merged
* variadic-array argument. Note that this is always the case for
* functions taking a VARIADIC argument type other than VARIADIC ANY.
*
* In principle, if VARIADIC wasn't originally specified and the array
* actual argument is deconstructable, we could print the array elements
* separately and not print VARIADIC, thus more nearly reproducing the
* original input. For the moment that seems like too much complication
* for the benefit, and anyway we do not know whether VARIADIC was
* originally specified if it's a non-ANY type.
* We always print VARIADIC if the function has a merged variadic-array
* argument. Note that this is always the case for functions taking a
* VARIADIC argument type other than VARIADIC ANY. If we omitted VARIADIC
* and printed the array elements as separate arguments, the call could
* match a newer non-VARIADIC function.
*/
if (use_variadic_p)
{