From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: new aggregate functions v1 |
Date: | 2004-05-02 15:19:22 |
Message-ID: | Pine.GSO.4.58.0405021705070.2462@chailly99 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Dear Peter,
> We are not going to accept any functions that are primarily intended to
> access the internals aclitem data. You need to think of a high-level
> description of your problem and implement functions for that.
I already have what I juge a "high level description" of the problem,
thanks. It nevertheless still use the acl bitfield for representings
granted rights. I don't think the bitfield is a bad idea to represent a
set of rights, as they are easy to combine (say, with a bit and aggregate
to compute effective rights for instance). My problem rather is to deal
with arrays in a relationnal query. It is not easy to query things when
data are not normalized.
So I will still need bit_* functions. I can implement them outside for
sure, but I really think that it does cost nothing to propose them as a
default (only the declaration is needed), and I know I'm not the first one
to look for them and being desappointed not to find them (there was a
discussion about these very functions last month on some other pg list).
Although It is very interesting to learn about how to add aggregates in
pg, maybe all users around don't have the time and the motivation for
that.
--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2004-05-02 15:22:04 | new aggregate functions v2 |
Previous Message | Peter Eisentraut | 2004-05-02 13:11:53 | Re: new aggregate functions v1 |