Re: merging some features from plpgsql2 project

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>
Subject: Re: merging some features from plpgsql2 project
Date: 2016-12-28 19:45:41
Message-ID: CAFj8pRB0LfCAAH-epHfsPDkLr9p=EKgLszZem5NhOEmO7yszWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2016-12-28 20:25 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> 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.
>
>
we can have both - plpgsql.variable_conflict can be precedent.

> 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.

yes, without GUC you cannot set the behave of plpgsql globally.

Regards

Pavel

>
> --
> 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)
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2016-12-28 20:43:21 Re: Vacuum: allow usage of more than 1GB of work mem
Previous Message Jim Nasby 2016-12-28 19:25:33 Re: merging some features from plpgsql2 project