Re: Quoting fun
От | Tom Lane |
---|---|
Тема | Re: Quoting fun |
Дата | |
Msg-id | 15311.965528396@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Quoting fun (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > I've been looking at SQL99 while reviewing a book, and stumbled across > some (new to me) behavior for double-quoted identifiers. The SQL99 way > to embed a double-quote into a quoted identifier is to put in two > adjacent double-quotes (much like is done for embedding single-quotes > into string literals in SQL9x). I looked at doing that a while ago, not because I knew it was in SQL99 but just because it seemed like a nice idea. I backed off though when I realized that there are a *lot* of places that will break. scan.l and pg_dump are just the tip of the iceberg --- there are many other places, and probably lots of applications, that assume printing "%s" is sufficient to protect an identifier. Be prepared for a lot of mop-up work if you want to press forward with this. > Currently, pg_dump escapes this by embedding a backslash/double-quote > pair, pg_dump is mistaken --- as you say, the backend doesn't accept backslashes in doublequoted idents. (Since there is no way to get a doublequote into an ident currently, pg_dump's check is dead code, which is why no one noticed it was broken.) > String literals can contain escaped characters, which postgres removes > early in the parsing stage. These escapes are re-inserted *every time > the string is returned in a query*. Au contraire, the backend never re-inserts escapes. regards, tom lane
В списке pgsql-hackers по дате отправления: