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 <andrew@dunslane.net>) |
| Ответы |
Re: Re: [COMMITTERS] pgsql: Close previously open holes
for invalidly encoded data to enter
|
| Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> 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 по дате отправления: