Re: [HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-11-01 Thread Andrew Dunstan
Bruce Momjian wrote: 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. One of the reasons we dropped it was that the spec didn't seem to make sense. So if there's a proposal

Re: [HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-11-01 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Andrew Dunstan wrote: >> No, we're long past this point. We've dropped 'convert ... using' entirely. > The question is whether re-adding it should be a TODO. Not unless someone wants it and can explain the spec convincingly. reg

Re: [HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-11-01 Thread Bruce Momjian
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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-11-01 Thread Andrew Dunstan
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 c

Re: [HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-11-01 Thread Bruce Momjian
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_usi

Re: [HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-09-18 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> 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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-09-18 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> 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

[HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-09-18 Thread Andrew Dunstan
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

[HACKERS] Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter

2007-09-18 Thread Andrew Dunstan
Tom Lane wrote: [EMAIL PROTECTED] (Andrew Dunstan) writes: Log Message: The two argument form of convert() is gone, Um ... so that means CONVERT(c USING y) now fails entirely? That might be going a bit far. If we do want to get rid of that syntax then I'm noting a lack of parser ch