Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group