On 9/1/14 12:12 PM, Andres Freund wrote:
> On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
>> On 9/1/14 11:53 AM, Hannu Krosing wrote:
>>>> You're going to have to find a more gradual way of doing this.
>>> Probably a better way (and there has been some talk of it) is
>>> having some kind of PRAGMA functionality, or pl/pgsql specific
>>> LOCAL SET to affect "just this function" and not spill to nested
>>> functions as is the case for SETs now.
>>
>> I can't imagine how that would work for anyone who has thousands of
>> functions.
>
> How's that fundamentally different from changing languages? If we had a
> way to *add* such attributes to *existing* functions I don't see the
> fundamental problem?
Adding 5-10 of these for every function you create seems significantly
more painful than saying "this function uses plpgsql2". Though perhaps
what's being suggested is a *single* option which changes everything at
once? Then there wouldn't be a huge difference.
>> I've tried my best over the past ~year or so, but any attempts at breaking
>> backwards compatibility have been rejected. I really don't see any gradual
>> way of doing this. We either break things, live with what we have right
>> now, or create a new language.
>
> I think to some degree that was also influenced by the approach you
> took. Several of the changes didn't really have a meaningful explanation
> why they'd be helpful in the field. I.e. the change was explained, but
> not the reasoning *leading* to the change and which other solutions you
> thought about.
Yes, I agree I didn't always do a terrific job (see: EXIT USING
ROLLBACK), but some of them have been outright rejected even though
people clearly saw the value (I would put ASSERT into that category, and
the change to SELECT .. INTO obviously belongs here).
.marko