Re: Making TEXT NUL-transparent

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Florian Weimer <fweimer(at)bfk(dot)de>, Alexander Shulgin <ash(at)commandprompt(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Making TEXT NUL-transparent
Date: 2011-11-24 16:47:16
Message-ID: 24421.1322153236@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On Thu, Nov 24, 2011 at 4:54 AM, Florian Weimer <fweimer(at)bfk(dot)de> wrote:
>> By the way, I refuse the notion that UTF-8 strings with embedded NULs
>> are "broken". I can't recall any other system which enforces UTF-8
>> well-formedness, but does not permit embedded NULs.

> Refuse away, but I don't think you know what you're asking for. Given the
> number of places that treat text values as being nul-terminated in the
> code, we'd be many years fixing bugs from a change like this, IMNSHO.

Yeah. This has been discussed before (see the archives) and every time
we've concluded that the amount of pain and developer effort would
outweigh the benefit by many orders of magnitude. Just to start with,
we'd have to change the convention that datatype I/O functions take and
return cstring, thus breaking every core and add-on datatype.

If you really need to store nulls, use bytea. If there are specific
operations you need that aren't available on bytea, we'd probably
entertain proposals to add them.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-24 16:47:31 Re: Wire protocol: type-specific opt-in to binary format
Previous Message Pavel Stehule 2011-11-24 16:44:16 Re: proposal: better support for debugging of overloaded functions