AHA! I hadn't encountered any null values in my bitstrings.
and having to include 'where xxx is not null' is rather
inconvenient and easy to forget.
indeed bitor(B'1000',null) returns null
but as a test, i nulled one row's data (the bitstring column portion only)
and my orsum without INITCOND returned the proper OR of the remaining values
when including all rows in the aggregate. it did not return null.
maybe the aggregator (whoever,whatever that is) handles null args differently,
not calling the func when the arg is null?
pg8.1.3
TJ
Florian G. Pflug wrote:
> TJ O'Donnell wrote:
>
>>> create aggregate or_bit64(
>>> basetype=bit,
>>> sfunc=bitor,
>>> stype=bit,
>>> initcond=
>>> '0000000000000000000000000000000000000000000000000000000000000000'
>>> ) ;
>>>
>>> I'm using this in production, and it works fine. I didn't find a way to
>>> make this length-agnostic, so I defined this for all lenghts of
>>> bitstrings the my app uses (32 and 64).
>>>
>>> greetings, Florian Pflug
>>
>>
>> I've created a similar aggregate using:
>> CREATE AGGREGATE gnova.orsum (
>> BASETYPE = bit,
>> SFUNC = bitor,
>> STYPE = bit
>> );
>> Notice, not using INITCOND allows bit of any length. While it may be
>> poor programming practice to not initialize, the docs say:
>> "If it is not supplied then the state value starts out null."
>> which is good enough for this old programmer. AND it works :)
>
> The problem was, as far as I remember, that bitor returns NULL if any
> of it's arguments is null. So not specifying an INITCOND makes the
> aggregate work for any length, but always returns null then...
>
> greetings, Florian Pflug