Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter
От
Tom Lane
Тема
Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter
Дата
Msg-id
11947.1190157936@sss.pgh.pa.us
Ответ на
Re: [COMMITTERS] pgsql: Close previously open holes for invalidly
encoded data to enter (Andrew Dunstan)
Список
Дерево обсуждения
Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter Tom Lane <tgl@sss.pgh.pa.us>
Re: [COMMITTERS] pgsql: Close previously open holes for invalidly
encoded data to enter Andrew Dunstan <andrew@dunslane.net>
Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter Tom Lane <tgl@sss.pgh.pa.us>
Re: [COMMITTERS] pgsql: Close previously open holes for invalidly
encoded data to enter Andrew Dunstan <andrew@dunslane.net>
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>
Re: Re: [COMMITTERS] pgsql: Close previously open
holes for invalidly encoded data to enter Bruce Momjian <bruce@momjian.us>
Re: Re: [COMMITTERS] pgsql: Close previously open holes
for invalidly encoded data to enter Andrew Dunstan <andrew@dunslane.net>
Re: Re: [COMMITTERS] pgsql: Close previously open
holes for invalidly encoded data to enter Bruce Momjian <bruce@momjian.us>
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>
Andrew Dunstan 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 по дате отправления