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. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
