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

From Bruce Momjian
Subject Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter
Date
Msg-id 200711012323.lA1NNEq12594@momjian.us
Whole thread Raw
In response to Re: 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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan wrote:
> 
> 
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >   
> >> Tom Lane wrote:
> >>     
> >>> OTOH we may be talking at cross-purposes --- on looking into gram.y
> >>> I see that this syntax is transformed to a call of convert_using(),
> >>> which may mean it has nothing to do with your changes.
> >>>
> >>>     
> >>>   
> >>>       
> >> No, I changed convert_using - 
> >> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/pg_conversion.c?r1=1.36&r2=1.37
> >>
> >> We can revert that if necessary. It will open up a hole, though. Take 
> >> your pick - spec compliance or validly coded data.
> >>     
> >
> > Is this a TODO?
> >   
> 
> No, we're long past this point. We've dropped 'convert ... using' entirely.

The question is whether re-adding it should be a TODO.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter