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

psql strings and ''

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeremy Drake <pgsql(at)jdrake(dot)com>
Subject: psql strings and ''
Date: 2006-05-29 21:47:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Currently, psql single-quote argument strings can only embed single
quotes as \', not ''.  This is because while the main psqlscan.l loop
understands '', the subsections used for psql arguments, xslasharg,
doesn't.  This patch attempts to fix that.  

However, I am not sure it is done right because I am not using the xe
and xq state values, like the main psql scanner code.  I assume we can
not use them because we are already in xslasharg, and can't add another
state here.

The unusual thing is that in my testing it worked anyway.


Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
>   EnterpriseDB
>   + If your life is a hard drive, Christ can be your backup. +
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?

  Bruce Momjian

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-05-29 21:50:05
Subject: Re: pg_proc probin misuse
Previous:From: Bruce MomjianDate: 2006-05-29 21:42:47
Subject: Re: [HACKERS] psql \copy warning

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-05-30 01:29:28
Subject: Re: Proposed doc-patch: Identifying the Current WAL file
Previous:From: Bruce MomjianDate: 2006-05-29 21:42:47
Subject: Re: [HACKERS] psql \copy warning

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