Re: [HACKERS] merging some features from plpgsql2 project - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] merging some features from plpgsql2 project
Date
Msg-id efd70d48-9f78-9ca8-88c1-b7cf775ccd3a@BlueTreble.com
Whole thread Raw
In response to Re: [HACKERS] merging some features from plpgsql2 project  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] merging some features from plpgsql2 project  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] merging some features from plpgsql2 project  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 12/28/16 12:51 PM, Pavel Stehule wrote:
> Now, the incompatibility can be hard issue - it is big question if we
> lock some users on old versions because some users can save to lines of
> code. Introduction of ROW_COUNT is lowly incompatibility - it can be
> simply detected - but for example change of behave of FOUND variable is
> terrible, because the code will be quietly calculate differently.
> sometimes we can break code - probably people will not be happy, but
> sometimes we can change the results - it can be big fail. So on one side
> is big costs. On second side is few lines less code.

That's my whole point of why this needs to be settable at a global 
level: so that people with a lot of legacy code can set the OLD behavior 
at a global level, and deal with the old code over time.

If there's no global setting then there are only two choices: we default 
to new behavior and force everyone to add a bunch of stuff to *every* 
function they have (loads of complaints), or we default to old behavior 
and no one bothers to even adopt the new usage because they have to add 
extra stuff to every function. Either way is a failure. This is why I 
think there MUST be some way to control this at a higher level than per 
function.

Certainly GUCs aren't the only option, we could invent something else. 
One feature I could see being useful is being able to set a default on a 
schema level, which isn't currently possible with a GUC. But I can 
certainly see database and global settings being useful, and perhaps 
per-user as well. GUCs already have those.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Improving RLS planning
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] merging some features from plpgsql2 project