[..]
>> A message for postgresql decision board:
>>
>> Dear postgresql hackers, if I can do something to push row level acl
>> for 8.4 please tell me, I do anything to have this feature, it will
>> help me, and I hope many others, this feature will help to develop
>> client to postgres applications without a server application or tones
>> of triggers and viewers.
>
> I can understand your pains and you want the row-level security stuffs
> to be merged within the vanilla v8.4. However, I would like you to
> understand we don't have infinite time to review proposed features
> for the upcoming v8.4.
I don't want to be to selfish , but AFAIK postgresql is already delayed
(according to PostgreSQL_8.4_Development_Plan page
"http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan" beta1
should be out on 1st January 2009), so, what's matter another 2-3 weeks of
delay?
Or, maybe, I'm the only one who consider this a *must to have* feature.
> Thus, I separated a few features (including row-level facility) to
> reduce the scale of patches, and the dieted patches are now under
> reviewing.
> If we change our strategy *from now*, it will break anything. :(
>
Don't understand me wrong, the last thing I want is an unstable postgresql
server.
>
> At least, I'll provide row-level facilities (both DAC and MAC) for the
> first CommitFest of v8.5 development cycle. It might not be the best
> for you, but it is better than nothing in v8.4.
>
I hope you will provide patches against 8.4.x, I don't want to wait 1-2
years until 8.5 will be out to use this feature. This is why I want to
help you (with more complex testings or *anything* you or others ask me)
to push row level acl to vanilla 8.4, that why I don't think 2-3 more
weeks matter.
PLEASE try to push this patches to 8.4 (I don't see row level acl here:
http://wiki.postgresql.org/wiki/CommitFestInProgress).
Thanks,
BogDan,
[..]
