Re: Detecting change in event properties

From: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
To: David Johnston <polobo(at)yahoo(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Detecting change in event properties
Date: 2013-10-26 07:11:33
Message-ID: B6F6FD62F2624C4C9916AC0175D56D880CE43434@jenmbs01.ad.intershop.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


>Marc Mamin-2 wrote
>> I would misuse GUC variables for this.
>> (using the functions current_setting and set_config)
>>
>> define a set get and switch fuction (I use operators for better
>> readability)
>> something like:
>>
>> select 'a' ==> 'foo'
>> 'a'
>> select 'b' <==> 'foo'
>> 'a'
>> select <== 'foo'
>> 'b'
>>
>>
>> and in your query:
>>
>> SELECT
>> case when test then col <==> 'foo' else <== 'foo' end
>
>Is it possible to alter GUC on a record-by-record basis?

yes, the underlying functions are volatile.
Which quite certainly imply that you cannot repeat the statement within a GROUP or ORDER BY...
And you must of course ensure that it get called on an ordered set.

>Is this something you have actually done?

yes

>
>Even if it does technically work this seems like a last-resort kind of
>solution. The syntax (though that could be hidden in a wrapper function) is
>definitely unusual and the abuse of the GUC system in this manner is
>surprising.

Sure. There are a some caveat too:

- it is quite slow

- you should first initialize the GUC to avoid testing it in each call.
This should be feasable with an extra function in a top WITH clause

- GUC are stored as text. You need to define functions for each type you are interested in.
This implies extra work for casting/decasting

- NULLs are transformed to empty strings per default, so you may need to care for this in your functions.

Marc Mamin

>
>David J.
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2013-10-26 13:53:06 Re: Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1
Previous Message Alan Nilsson 2013-10-26 06:28:11 Re: Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1