Re: [HACKERS] Incautious handling of overlength identifiers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Incautious handling of overlength identifiers
Дата
Msg-id 7096.1482773527@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Incautious handling of overlength identifiers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Incautious handling of overlength identifiers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
I wrote:
> Another idea worth considering is to just make the low-level functions
> do truncation ...

After further thought, there's a bigger-picture issue here, which
is whether the inputs to the SQL functions in question are intended to
be raw user input --- in which case, not only would truncation be
an appropriate service, but probably so would downcasing --- or whether
they are more likely to be coming from a catalog scan, in which case
you don't want any of that stuff.  Nobody's going to be happy if we
start making them add quote_ident() around references to name columns.
I think the privilege-inquiry functions are almost certainly mostly
used in the latter style; there might be more room for debate about,
say, pg_get_serial_sequence.

Since the low-level functions need to support both use cases, asking
them to handle truncation is wrong, just as much as it would be to
ask them to do downcasing.

If we take these SQL functions as being meant for use with inputs
coming from catalogs, then they don't need to do truncation for
user-friendliness purposes; it's perfectly fine to treat overlength
inputs as "name not found" cases.  So that says we could just remove
that Assert and decide we're done.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables