Fabien COELHO wrote:
> Dear Alvaro,
>
>> > (2) bitwise integer aggregates named bit_and and bit_or for
>> > int2, int4, int8 and bit types. They are not standard,
>> > however they exist in other db (eg mysql), and I needed them
>> > for some other stuff.
>>
>> I'm sure people won't like to add functions just because "some other DB
>> has them".
>
> I develop them because I NEEDED them, NOT because they are available
> in mysql and I would want compatibility. I needed them for some queries
> over pg_catalog, as acl are encoded as bitfields.
>
> So the addition is about functionnality, not compatibility.
>
> The argument about mysql is rather to show that other people in the world
> found these functions also useful, and to justify the name I chose.
The argument about MySQL (tm) is IMHO a good one, because in contrast to
MySQL (tm), PostgreSQL is designed and implemented as a catalog based
system. We carry the performance burden we always got blamed for
(unjustified because MySQL (tm) is slow as hell anyway) for a reason,
and the reason is flexibility. In MySQL (tm) you don't have a chance,
the functionality you want must be the functionality linked into the
server. With PostgreSQL you can add the functionality you need where and
when you need it.
>
> You may also notice that the impact in close to void, there are two lines
> added for each of these bit_* functions. I'm not going to develop an
> external package for 16 lines of code.
>
Maybe I'm missing something, but what is wrong with installing these
functions on demand as user defined functions? After all, even PL/pgSQL
is still an external package ... sort of at least.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
