Tim Bunce wrote:
But that's quite different from us providing an undocumented way to
expose arbitrary objects to the Safe container. In that case *we*
become responsible for any insecure uses, and we don't even have the
luxury of having put large warnings in the docs, because there
aren't any docs.
I wish I understood better how PostgreSQL developers would be
responsible for a DBA using an undocumented hack. In my view the DBA is
clearly responsible in that case.
If it's not documented it's not supported.
My feeling is if we provide something we are responsible for it,
documented or not. Undocumented features with security implications
raise big red flags in my head. Maybe the difference in perspective
comes from working on a database as opposed to working on a language.
I still think if we do this at all it needs to be documented and
surrounded with appropriate warnings.
I'm away for a day or so (for my wedding anniversary) but I'll have an
updated patch, with a clean well-documented API, for consideration by
Monday morning.
Happy anniversary! But on reflection I think it's too late for this. We
are a month into the commitfest. Alex's suggestion on how to proceed
(change the declarations on the relevant items to make them
inaccessible) makes sense to me.
We've always been fighting time on these PLPerl patches and we're
moderately lucky to have got as much in as we have.
In case I haven't said it before, your work on this is very much
appreciated.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
