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
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2010-02-13 16:30:36|
|Subject: Re: Small Bug in pgstat display during recovery conflict resolution|
|Previous:||From: Matteo Beccati||Date: 2010-02-13 12:34:56|
|Subject: Re: mailing list archiver chewing patches|