On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne <cbbro...@acm.org> wrote: > mmonc...@gmail.com (Merlin Moncure) writes: >> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure <mmonc...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
