Prev: Using Small Size SSDs to improve performance?
Next: Secret of super bone0n
From: Tom Lane on 4 Aug 2010 19:00
Merlin Moncure <mmoncure(a)gmail.com> writes:
> While chatting with Haas off-list regarding how the new array/string
> functions should work (see the thread in its glory here:
> http://www.mail-archive.com/pgsql-hackers(a)postgresql.org/msg148865.html)
> the debate morphed into the relative pros and cons about the proposed
> concat() being marked stable vs immutable. I did some checking into
> how things work now, and found some surprising cases.

Er ... "now" being defined as what? I can't replicate your results in
HEAD. In particular, textanycat isn't immutable anymore.

The DROP CAST case is a bit interesting. We don't record a dependency
on the cast as such, but on the underlying function --- if you'd tried
to drop the function you'd not have been allowed to. It is a bit
peculiar that dropping the cast causes the meaning of a::text to change,
but I'm not sure there's much we can do about that. In any case, it
seems like that's not nearly as much of a hazard as doing CREATE OR
REPLACE FUNCTION and changing the computation done by the function.
We could disallow that maybe, but that cure seems worse than the
disease.

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: Merlin Moncure on 4 Aug 2010 19:43
On Wed, Aug 4, 2010 at 7:00 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure(a)gmail.com> writes:
>> While chatting with Haas off-list regarding how the new array/string
>> functions should work (see the thread in its glory here:
>> http://www.mail-archive.com/pgsql-hackers(a)postgresql.org/msg148865.html)
>> the debate �morphed into the relative pros and cons about the proposed
>> concat() being marked stable vs immutable. �I did some checking into
>> how things work now, and found some surprising cases.
>
> Er ... "now" being defined as what? �I can't replicate your results in
> HEAD. �In particular, textanycat isn't immutable anymore.

ah, my mistake. I'm using a fairly old build of 9.0.

> The DROP CAST case is a bit interesting. �We don't record a dependency
> on the cast as such, but on the underlying function --- if you'd tried
> to drop the function you'd not have been allowed to. �It is a bit
> peculiar that dropping the cast causes the meaning of a::text to change,
> but I'm not sure there's much we can do about that. �In any case, it
> seems like that's not nearly as much of a hazard as doing CREATE OR
> REPLACE FUNCTION and changing the computation done by the function.
> We could disallow that maybe, but that cure seems worse than the
> disease.

yep (the textanycat was much more interesting to me)

merlin

--
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 4 Aug 2010 21:31
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.

--
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

From: Merlin Moncure on 4 Aug 2010 23:46
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?

merlin

--
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: Merlin Moncure on 5 Aug 2010 13:26
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.

hm -- interesting -- couldn't that cause exactly the sort of situation
though where stability of statement is violated?

merlin

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

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