Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter
Date
Msg-id 11947.1190157936@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> We can revert that if necessary. It will open up a hole, though. Take 
> your pick - spec compliance or validly coded data.

I would rather take CONVERT USING out altogether, than have an
implementation that so clearly disregards the spec as to not even return
a compatible datatype.

Other than the fact that it's supposed to return varchar, the spec's
description of what it converts to what seems about as clear as mud.
I suspect however that it can't really be implemented properly without
support for per-value (or at least per-column) encoding, which is
something we're nowhere near having.  Maybe we *should* take it out
instead of using spec-defined syntax for a behavior that we made up
out of whole cloth.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_ctl -w vs unix_socket_directory
Next
From: Gregory Stark
Date:
Subject: Re: invalidly encoded strings