Re: log bind parameter values on error

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: log bind parameter values on error
Дата
Msg-id 8464.1575924424@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: log bind parameter values on error  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: log bind parameter values on error  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Also:
> * v18 and v19 now alwys do a "strlen(s)", i.e. they scan the whole input
>   string -- pointless when maxlen is given.  We could avoid that for
>   very large input strings by doing strnlen(maxlen + MAX_MULTIBYTE_CHAR_LEN)
>   so that we capture our input string plus one additional multibyte
>   char.

BTW, as far as that goes, it seems to me this patch is already suffering
from a lot of premature micro-optimization.  Is there even any evidence
to justify that complicated chunk-at-a-time copying strategy, rather than
doing quote-doubling the same way we do it everywhere else?  The fact that
that effectively scans the input string twice means that it's not an
ironclad win compared to the naive way, and it seems like it could lose
significantly for a case with lots of quote marks.  Moreover, for the
lengths of strings I expect we're mostly dealing with here, it would be
impossible to measure any savings even assuming there is some.  If I were
the committer I think I'd just flush that and do it the same way as we
do it in existing code.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: log bind parameter values on error
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Index corruption / planner issue with one table in my pg 11.6 instance