Skip site navigation (1) Skip section navigation (2)

Re: arrays as pl/perl input arguments [PATCH]

From: Alexey Klyukin <alexk(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: arrays as pl/perl input arguments [PATCH]
Date: 2011-01-12 13:34:06
Message-ID: 18092504-7B2C-4115-973C-17F806FE9513@commandprompt.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:

> On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On 01/11/2011 07:17 PM, David E. Wheeler wrote:
>>> On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
>>> 
>>>> I think there's at least a danger of breaking legacy code doing that. Say
>>>> you have some code that does a ref test on the argument, for example. The
>>>> behavior would now be changed.
>>> 
>>> I think that'd be pretty rare.
>> 
>> Possibly it would. But we usually try pretty hard to avoid that sort of
>> breakage.
> 
> By the same token, I'm not convinced it's a good idea for this
> behavior to be off by default.  Surely many people will altogether
> fail to notice that it's an option?  If we're going to have a
> backward-compatibility GUC at all, ISTM that you ought to get the good
> stuff unless you ask for the old way.

I think the number of people failing to notice the changes would be the same whenever we set the new or the old behavior by default. I decided to default to the the old behavior since it won't break the existing code as opposed to just hiding the good stuff, although it would slower the adoption of the new behavior.

/A

--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.





In response to

Responses

pgsql-hackers by date

Next:From: Joel JacobsonDate: 2011-01-12 13:51:29
Subject: Re: pg_depend explained
Previous:From: Noah MischDate: 2011-01-12 13:14:51
Subject: Re: ALTER TYPE 1: recheck index-based constraints

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group