Re: DOMAINs and CASTs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Darren Duncan <darren(at)darrenduncan(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DOMAINs and CASTs
Date: 2011-06-13 13:44:33
Message-ID: BANLkTin5WtcAaLo2j2vUGNhGasQC2dFZFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 13, 2011 at 4:39 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-06-13 13:49:49 Re: Boolean operators without commutators vs. ALL/ANY
Previous Message Robert Haas 2011-06-13 13:42:05 Re: FOREIGN TABLE doc fix