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 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 по дате отправления
От: Andrew Dunstan
Дата:
От: Gregory Stark
Дата:
Сообщение: Re: invalidly encoded strings
FAQ