Re: Two different methods of sneaking non-immutable data into an index - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Two different methods of sneaking non-immutable data into an index
Date
Msg-id AANLkTik3HphQCf0sb=P+=ymU4kCCjbKrbTs4xEeMotPB@mail.gmail.com
Whole thread Raw
In response to Re: Two different methods of sneaking non-immutable data into an index  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> *) also, isn't it possible to change text cast influencing GUCs 'n'
>> times per statement considering any query can call a function and any
>> function can say, change datestyle?  Shouldn't the related functions
>> be marked 'volatile', not stable?
>
> This is just evil.  It seems to me that we might want to instead
> prevent functions from changing things for their callers, or
> postponing any such changes until the end of the statement, or, uh,
> something.  We can't afford to put ourselves in a situation of having
> to make everything volatile; at least, not if "performance" is
> anywhere in our top 50 goals.


yeah -- perhaps you shouldn't be allowed set things like datestyle in
functions then.  I realize this is a corner (of the universe) case,
but I can't recall any other case of volatility being relaxed on
performance grounds... :-).  Maybe a documentation warning would
suffice?

merlin


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: documentation for committing with git
Next
From: Pavel Stehule
Date:
Subject: Re: GROUPING SETS revisited