Jasen Betts writes:
> On 2013-03-26, Tom Lane wrote:
>> The manual says that 'escape' encoding "merely outputs null bytes as
>> \000 and doubles backslashes".
>> (Having said that, I wonder though if "escape" doesn't need more
>> thought. The output is only valid text in SQL_ASCII or single-b
On 2013-03-26, Tom Lane wrote:
> The manual says that 'escape' encoding "merely outputs null bytes as
> \000 and doubles backslashes".
> (Having said that, I wonder though if "escape" doesn't need more
> thought. The output is only valid text in SQL_ASCII or single-byte
> encodings, otherwise
Bill Moran writes:
> If I just do:
> SELECT 'can''t'::text;
> I get "can't" which is what I'd expect. I would then expect
> encode to escape the ' somehow. Even c-style escaping, like
> "can\'t" would have been less surprising to me.
> If there's something I'm missing, I'm still missing it.
Th
On Tue, Mar 26, 2013 at 1:36 PM, Bill Moran wrote:
> I get "can't" which is what I'd expect. I would then expect
> encode to escape the ' somehow.
nope -- encode/escape doesn't escape single quotes. it's not designed
to produce output that can be fed directly back into the database (at
least, no
In response to Merlin Moncure :
> On Tue, Mar 26, 2013 at 12:47 PM, Bill Moran wrote:
> >
> > psql -U postgres
> > psql (9.2.3)
> > Type "help" for help.
> >
> > postgres=# select encode('can''t', 'escape');
> > encode
> >
> > can't
> > (1 row)
> >
> > I observed the same behaviour on
On Tue, Mar 26, 2013 at 12:47 PM, Bill Moran wrote:
>
> psql -U postgres
> psql (9.2.3)
> Type "help" for help.
>
> postgres=# select encode('can''t', 'escape');
> encode
>
> can't
> (1 row)
>
> I observed the same behaviour on one of our older systems (8.3.11) as well.
>
> Am I missing
