Re: DOMAINs and CASTs

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: DOMAINs and CASTs
Дата
Msg-id BANLkTin5WtcAaLo2j2vUGNhGasQC2dFZFw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: DOMAINs and CASTs  (Jaime Casanova <jaime@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Jun 13, 2011 at 4:39 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
> On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
>>> On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> >
>>> > The more controversial question is what to do if someone tries to
>>> > create such a cast anyway.  We could just ignore that as we do now, or
>>> > we could throw a NOTICE, WARNING, or ERROR.
>>>
>>> IMHO, not being an error per se but an implementation limitation i
>>> would prefer to send a WARNING
>>
>> Implementation limitations are normally reported as errors.  I don't see
>> why it should be different here.
>>
>
> ok, patch reports an error... do we want to backpatch this? if we want
> to do so maybe we can backpatch as a warning

I'm not even really sure I want an ERROR anywhere.  If it weren't
something we have accepted previously, I'd be all in favor, but I'm
unconvinced it's worth breaking people's dumps over this.

As far as the back-branches go, I'd be inclined to back-patch only a doc fix.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: FOREIGN TABLE doc fix
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Boolean operators without commutators vs. ALL/ANY