Re: PG secure for financial applications ... - Mailing list pgsql-general

From Micah Yoder
Subject Re: PG secure for financial applications ...
Date
Msg-id 200803141022.57808.micah@yoderdev.com
Whole thread Raw
In response to Re: PG secure for financial applications ...  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Responses Re: PG secure for financial applications ...  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
List pgsql-general
Thanks for the replies.  That's kind of what I figured, though it would be
interesting if it were possible.  For example, if a financial institution
could allow their clients direct connections to a database, the clients (or
anyone) could build absolutely any interface to it they want.  I think that
would be awesome.

I was also thinking a bit more broad than just finance.  Could PG be used, for
example, as a multiplayer strategy game server where clients can directly
connect without another middleware daemon?  Seems to me like it has
everything necessary, except for this problem.

Perhaps this could be worked around by building a slim proxy for PG
connections (and maybe one exists, I haven't looked).  All it would really
need to do, I think, is filter BEGIN commands so clients could not start
transactions to hold locks.  All tables would be non-accessible to clients
except through SECURITY DEFINER functions, so I don't think there's any other
way they could grab a lock, or cause too much trouble (correct me if I'm
wrong!).

> You cannot manage transactions inside functions. A function always
> runs inside a single transaction.

Actually from the pl/pgsql manual it looks like you can raise an error and
have it abort the surrounding transaction.  If that's true it should be
robust.

Thanks,
Micah


pgsql-general by date:

Previous
From: luca.ciciriello@email.it
Date:
Subject: Re: LOCK TABLE HELP
Next
From: Greg Smith
Date:
Subject: Re: pgbench not setting scale size correctly?