Re: [HACKERS] psql \copy warning
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] psql \copy warning |
Дата | |
Msg-id | 200605290405.k4T45Wc25456@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql \copy warning (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] psql \copy warning
psql strings and '' |
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Right. I think the question is whether we want all psql strings to > > accept backslashes, and hence not support E'' at all for psql commands. > > I figured that made the most sense. > > I'm not convinced. Wouldn't it be better if psql commands track the > backend syntax? With standard_conforming_strings on, there will be two > ways to tell COPY you want a tab as a delimiter: > DELIMITER '<actual tab char>' > DELIMITER E'\t' > and in particular this will NOT do that: > DELIMITER '\t' Well, I think it a little more confusing that just \copy. What about \d and \set uses of backslashes. Do they honor standard_conforming_strings too? I assume you are saying they should. > If we keep '\t' as meaning tab in the \copy syntax then I think we're > going to cause confusion in the long run. I think we should fix \copy > and related psql backslash commands to accept E'\t', and make sure that > the behavior is the same as the connected backend depending on what its > standard_conforming_strings setting is. OK, though this is going to mean that examples in the psql manual page are going to be different for different standard_conforming_strings settings: testdb=> \set content '\'' `cat my_file.txt` '\'' testdb=> INSERT INTO my_table VALUES (:content); psql doesn't know '''' is about doubling single quotes in a string, though \copy does. The major problem, I think, is that psql often follows the shell rules, rather than the SQL rules for most things. > There is a secondary, largely cosmetic question of whether psql should > attempt to prevent you from seeing escape_string_warning messages. > I personally have come to the conclusion that escape_string_warning is > probably not going to be on by default anyway ;-), and hence it's not > worth going to great extremes to prevent this, particularly if it breaks > the ability to use psql against pre-8.1 servers. It does break backward compatibility. -- 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 по дате отправления: