Re: Quoting fun

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Quoting fun
Date: 2000-08-06 02:19:56
Message-ID: 15311.965528396@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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

In response to

  • Quoting fun at 2000-08-05 04:05:20 from Thomas Lockhart

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-08-06 02:27:37 Re: COALESCE implementation question
Previous Message Tom Lane 2000-08-06 02:05:21 Re: Re: [GENERAL] random() function produces wrong range