Re: Fixing backslash dot for COPY FROM...CSV
От | Tom Lane |
---|---|
Тема | Re: Fixing backslash dot for COPY FROM...CSV |
Дата | |
Msg-id | 2726138.1712462833@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fixing backslash dot for COPY FROM...CSV (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Fixing backslash dot for COPY FROM...CSV
|
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > On Sun, Apr 7, 2024 at 12:00:25AM +0200, Daniel Verite wrote: >> Agreed we don't want to document that, but also why doesn't \. in the >> contents represent just a dot (as opposed to being an error), >> just like \a is a? > I looked into this and started to realize that \. is the only copy > backslash command where we define the behavior only alone at the > beginning of a line, and not in other circumstances. The \a example > above suggests \. should be period in all other cases, as suggested, but > I don't know the ramifications if that. Here's the problem: if some client-side code thinks it's okay to quote "." as "\.", what is likely to happen when it's presented a data value consisting only of "."? It could very easily fall into the trap of producing an end-of-data marker. If we get rid of the whole concept of end-of-data markers, then it'd be totally reasonable to accept "\." as ".". But as long as we still have end-of-data markers, I think it's unwise to allow "\." to appear as anything but an end-of-data marker. It'd just add camouflage to the booby trap. regards, tom lane
В списке pgsql-hackers по дате отправления: