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_using -

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

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 to do with your changes.

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. regards,

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

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

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