Dennis Bjorklund <db@zigo.dhs.org> writes:

> To insert a tab using readline you can press ESC followed by TAB.

....or ^V followed by TAB, as per age-old tradition. :-)

-tih
--
Don't ascribe to stupidity what can be adequately explained by ignorance.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Tue, 31 May 2005, Tom Ivar Helbekkmo wrote:

> ...or ^V followed by TAB, as per age-old tradition. :-)

Right, I forgot about that one. One can also do other control characters
instead of TAB by pressing CTRL-J and similar.

Well, I just wanted to point out that it's possible. The main problem is
still to make sure that old dumps work and can be imported. I don't see
how that can work without a GUC variable in addition to the E'foo' stuff
(but that's not so bad as it can be phased in to support old pg_dumps and
phased out again in pg 10 or something).

--
/Dennis Björklund


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > The only thing I'm not clear on is what exactly is the use case for E''
> > strings. That is, who do you expect to actually use them?
>
> The case that convinced me we need to keep some sort of backslash
> capability is this: suppose you want to put a string including a tab
> into your database. Try to do it with psql:
> t=> insert into foo values ('<TAB>
> Guess what: you won't get anywhere, at least not unless you disable
> readline. So it's nice to be able to use \t.
>
> There are related issues involving \r and \n depending on your platform.
> And this doesn't even scratch the surface of encoding-related funnies.
>
> So there's definitely a use-case for keeping the existing backslash
> behavior, and E'string' seems like a reasonable proposal for doing that
> without conflicting with the SQL spec.
>
> What I do not see at the moment is how we get there from here (ie,
> dropping backslashing in regular literals) without incurring tremendous
> pain --- including breaking all existing pg_dump files, introducing
> security holes and/or data corruption into many existing apps that are
> not presently broken, and probably some other ways of ruining your day.
> I'm quite unconvinced that this particular letter of the SQL spec is
> worth complying with ...

I think this is going to be like the Win32 port, where there is little
excitement from our existing users, but it is needed to grow our user
base.

I think the E'' is useful becuase it gives people a migration path for
the escapes they are already using, and the escape mechanism itself it
something useful to keep.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Tue, May 31, 2005 at 11:49:20 +0200,
Dennis Bjorklund <db@zigo.dhs.org> wrote:
> On Tue, 31 May 2005, Tom Lane wrote:
>
> > The case that convinced me we need to keep some sort of backslash
> > capability is this: suppose you want to put a string including a tab
> > into your database. Try to do it with psql:
> > t=> insert into foo values ('<TAB>
> > Guess what: you won't get anywhere, at least not unless you disable
> > readline. So it's nice to be able to use \t.
>
> To insert a tab using readline you can press ESC followed by TAB. This
> works as least in readline as it is setup in redhat/fedora (and readline
> can be setup in 1000 different ways so who knows how portable this is).

There are still advantages to having printable backslashed escaped characters
in strings that are saved to files. It makes it easier to see what is really
in the string and they are less likely to get accidentally munged when
editing the file or moving it between systems with different line termination
conventions.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Here is a summary of the issues with moving to no escapes for non-E
strings:

http://candle.pha.pa.us/cgi-bin/pgescape

---------------------------------------------------------------------------

Bruno Wolff III wrote:
> On Tue, May 31, 2005 at 11:49:20 +0200,
> Dennis Bjorklund <db@zigo.dhs.org> wrote:
> > On Tue, 31 May 2005, Tom Lane wrote:
> >
> > > The case that convinced me we need to keep some sort of backslash
> > > capability is this: suppose you want to put a string including a tab
> > > into your database. Try to do it with psql:
> > > t=> insert into foo values ('<TAB>
> > > Guess what: you won't get anywhere, at least not unless you disable
> > > readline. So it's nice to be able to use \t.
> >
> > To insert a tab using readline you can press ESC followed by TAB. This
> > works as least in readline as it is setup in redhat/fedora (and readline
> > can be setup in 1000 different ways so who knows how portable this is).
>
> There are still advantages to having printable backslashed escaped characters
> in strings that are saved to files. It makes it easier to see what is really
> in the string and they are less likely to get accidentally munged when
> editing the file or moving it between systems with different line termination
> conventions.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend