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