Re: [HACKERS] psql \copy warning
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] psql \copy warning |
Дата | |
Msg-id | 200605282356.k4SNugp13368@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql \copy warning (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The attached patch fixes the warning you received by adding E'' strings > > to the \copy arguments, and adds it for the other backslash commands > > like \d. > > Further comment on this: I don't think we want all these places > individually making this sort of decision. What they should all be > doing is using appendStringLiteralConn to generate the properly-quoted > literal. (I fixed this already in describe.c, but not in those other > places.) Yes, I think so. > Once we've got that done, we could argue about whether appendStringLiteral > ought to prepend an E to silence escape_string_warning. I'd still vote > no, but at least it would be a single place to change and not N of 'em. > What's more, each place that is generating a variable literal without > using appendStringLiteral or PQescapeString is at least potentially > vulnerable to encoding issues, and so we should probably convert them > anyway. True. See the email I just sent about escape_string_warning. FYI, we are finding these places because of escape_string_warning. Do we trust users to turn that on and test before standard_conforming_strings becomes true. One big problem is that people are having to use E'' if they want to keep using backslashes, even if they have already tested standard_conforming_strings. One nice thing about E'' is that it works no matter what the value of standard_conforming_strings is. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: