From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net>, Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpgsql.consistent_into |
Date: | 2014-01-14 01:27:35 |
Message-ID: | 52D49287.6020502@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/13/2014 05:10 PM, Jim Nasby wrote:
> On 1/13/14, 7:06 PM, Josh Berkus wrote:
>> Regularly? No. But I've seen it, especially as part of a "does this
>> query return any rows?" test. That's not the best way to test that, but
>> that doesn't stop a lot of people doing it.
>
> Right, and I certainly don't want to force anyone to rewrite all their
> code. But I'd certainly like a safer default so people don't mistakenly
> go the "multiple rows is OK" route without doing so very intentionally.
The problem is that if you change the default, you're creating an
unexpected barrier to upgrading. I just don't think that it's worth
doing so in order to meet some standard of code neatness, especially in
plpgsql, the unwanted bastard child of SQL and ADA.
For people who want to enable this in order to prevent stupid query bugs
from creeping into their plpgsql, that's great, let's have an easy
option to turn on. But it's hard enough to get people to upgrade as it
is. If we're going to add an upgrade landmine, it better be for
something really important.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-14 01:29:41 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Previous Message | Andres Freund | 2014-01-14 01:26:25 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |