Re: invalidly encoded strings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: invalidly encoded strings
Date: 2007-09-10 03:43:48
Message-ID: 16440.1189395828@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> In the short run it might be best to do it in scan.l after all.

> I have not come up with a way of doing that and handling the bytea case.

AFAICS we have no realistic choice other than to reject \0 in SQL
literals; to do otherwise requires API changes throughout that stack of
modules. And once you admit \0 is no good, it's not clear that
\somethingelse is any better for bytea-using clients. Moreover, given
that we are moving away from backslash escapes as fast as we can sanely
travel, expending large amounts of energy to make them work better
doesn't seem like a good use of development manpower.

> If you have I'm all ears. And then I am still worried about COPY.

Haven't looked at your test case yet... but it sure looks to me like the
COPY code *ought* to cover this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2007-09-10 03:52:33 Re: invalidly encoded strings
Previous Message Jeff Davis 2007-09-10 03:38:08 Re: invalidly encoded strings

Browse pgsql-patches by date

  From Date Subject
Next Message Jeff Davis 2007-09-10 03:52:33 Re: invalidly encoded strings
Previous Message Jeff Davis 2007-09-10 03:38:08 Re: invalidly encoded strings