Re: Two different methods of sneaking non-immutable data into an index

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Two different methods of sneaking non-immutable data into an index
Date: 2010-08-05 17:35:23
Message-ID: 87zkx12c9w.fsf@cbbrowne.afilias-int.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

mmoncure(at)gmail(dot)com (Merlin Moncure) writes:
> On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne <cbbrowne(at)acm(dot)org> wrote:
>> mmoncure(at)gmail(dot)com (Merlin Moncure) writes:
>>> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure <mmoncure(at)gmail(dot)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.
>
> hm -- interesting -- couldn't that cause exactly the sort of situation
> though where stability of statement is violated?

It shouldn't...

The data gets stored physically, on disk, in a canonical form.

Why should it be "unstable" to capture data in a canonical form, when
that's what gets stored on disk?
--
(format nil "~S(at)~S" "cbbrowne" "gmail.com")
The statistics on sanity are that one out of every four Americans is
suffering from some form of mental illness. Think of your three best
friends. If they're okay, then it's you. -- Rita Mae Brown

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-08-05 17:36:32 Re: Concurrent MERGE
Previous Message Kevin Grittner 2010-08-05 17:31:37 Re: Concurrent MERGE