Re: Name column - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Name column
Date
Msg-id AANLkTinr77Y51jUgGQrH5_VmLCxOQv74sG72azO8HdKJ@mail.gmail.com
Whole thread Raw
In response to Re: Name column  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Name column  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Sep 24, 2010 at 11:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> André Fernandes <andre.de.camargo.fernandes@hotmail.com> writes:
>>> On Fri, Sep 24, 2010 at 6:35 AM, Heikki Linnakangas
>>> <heikki.linnakangas@enterprisedb.com> wrote:
>>> I'm starting to wonder if we should think about deprecating this
>>> behavior.  It is awfully confusing and unintuitive.
>
>> I agree, it is very unintuitive.
>> +1  for deprecating this behavior.
>
> -1.  There's nothing wrong with the function-as-a-computed-column
> feature, and it seems likely that taking it away will break applications.
>
> What we are getting bit by is that I/O coercions to string types can be
> specified this way.  Maybe what we ought to do is remove just that one
> capability.  It'd be a bit non-orthogonal, but seems fairly unlikely to
> break anything, especially since we only began to allow such things
> recently (in 8.4 looks like).

I think that might be an improvement, but I'm not convinced it goes
far enough.  What evidence do we have that anyone is relying on this
behavior in applications?  Every report I've heard of it involved
someone being surprised that it worked that way.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Name column
Next
From: Andrew Dunstan
Date:
Subject: Re: Enable logging requires restart