Prev: Using Small Size SSDs to improve performance?
Next: Secret of super bone0n
From: Tom Lane on 5 Aug 2010 13:28
Chris Browne <cbbrowne(a)acm.org> writes:
> mmoncure(a)gmail.com (Merlin Moncure) writes:
>> yeah -- perhaps you shouldn't be allowed set things like datestyle in
>> functions then.

> That would cause grief for Slony-I, methinks, and probably other things
> that behave somewhat similar.

Yeah, it's not really practical (or useful IMO) to try to lock this down
completely.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 5 Aug 2010 14:02
On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne <cbbrowne(a)acm.org> wrote:
> mmoncure(a)gmail.com (Merlin Moncure) writes:
>> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
>>> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure <mmoncure(a)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?
>
> That would cause grief for Slony-I, methinks, and probably other things
> that behave somewhat similar.
>
> The "logtrigger()" function coerces datestyle to ISO, so that when dates
> get stored, they are stored in a canonical form, irrespective of an
> individual connection's decisions on datestyle, so we don't have to
> include datestyle information as part of the replicated data.

I think functions should be allowed to change GUCs internally, but
maybe not for the context from which they were called.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: Using Small Size SSDs to improve performance?
Next: Secret of super bone0n