[Pljava-dev] Re: JarOwner problem

Hi all,
? ?Pardons if this topic is located somewhere I have missed or has been
already discussed, but is there a plan to ever have table-level triggers? My
understanding is that current triggers fire on rows when an insert,
update or delete occurs.
? ?I was thinking it would be nice to have one at the table level (called once
for each result set on a table) with special attention to before/after
"reads". This would allow privileged access control mechanisms to be
developed for tables and pluggable via pljava. I know that there are some
inside the database already, but with a custom trigger, it could do things
like call out to a directory or some external resource to determine
visibility.

Is this even a good idea?

Thank you!
Darren

Darren,
SQL (and PostgreSQL) implements triggers that are fired 'for each
statement' or 'on each row'. PL/Java implements both. It is impossible
for a PL (any PL) to introduce new types of triggers. Ideas in that
direction is better debated on the PostgreSQL general mailing list. I
suspect however, that the postgresql community will be reluctant to
implement non-standard trigger types.

Kind regards,
Thomas Hallgren

that PostgreSQL has
dgovoni at metadapt.com wrote:
> Hi all,
> Pardons if this topic is located somewhere I have missed or has been
> already discussed, but is there a plan to ever have table-level triggers? My
> understanding is that current triggers fire on rows when an insert,
> update or delete occurs.
> I was thinking it would be nice to have one at the table level (called once
> for each result set on a table) with special attention to before/after
> "reads". This would allow privileged access control mechanisms to be
> developed for tables and pluggable via pljava. I know that there are some
> inside the database already, but with a custom trigger, it could do things
> like call out to a directory or some external resource to determine
> visibility.
>
> Is this even a good idea?
>
> Thank you!
> Darren
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/pljava-dev
>

Thomas,

I found a problem when using PostgreSQL 8.1 with pljava. PostrgreSQL 8.1 hid
the user system id from SQL interface, and consequently from a pg_dumpall
output as well.
It results in the fact that a database being dumped and reloaded does not
work properly because of the broken jarowner reference in
sqlj.jar_repository (a user who should own the jar has a different system id
after the reload).

I think we should find a solution for this problem. Unfortunately, this will
probably lead to a database table structure change (user name instead of the
system id). Or do you have any better idea?

Regards
Filip

Filip,
I wasn't aware of this and I agree, we need to change the table
structure as per your suggestion. Ouch! The 1.2 release would have been
the perfect time. Now it's too late. I guess we must do a 1.3 with this
change since it will be incompatible with prior releases.

Regards,
Thomas Hallgren

Filip Hrbek wrote:
> Thomas,
>
> I found a problem when using PostgreSQL 8.1 with pljava. PostrgreSQL
> 8.1 hid the user system id from SQL interface, and consequently from a
> pg_dumpall output as well.
> It results in the fact that a database being dumped and reloaded does
> not work properly because of the broken jarowner reference in
> sqlj.jar_repository (a user who should own the jar has a different
> system id after the reload).
>
> I think we should find a solution for this problem. Unfortunately,
> this will probably lead to a database table structure change (user
> name instead of the system id). Or do you have any better idea?
>
> Regards
> Filip
>