Tom Lane wrote:
>
> "Rod Taylor" <rbt@zort.ca> writes:
> > Looks like CommentOperator goes to quite a bit of work (5 lines) to
> > accomplish fetching the procedure and states specifically it's not a
> > bug.
>
> Yeah, someone once thought it was a good idea, but I was wondering about
> the wisdom of it just the other day. Currently this "feature" presents
> a hole in the security of comments on functions: anyone can make an
> operator referencing a function, and then they'll be allowed to set the
> function's comment :-(.
>
> I can see the value in having the function comment shown when there is
> no comment specifically for the operator ... but perhaps that ought to
> be implemented in the client requesters, rather than wired into the
> catalog representation.
>
> > In which case RemoveOperator needs to drop comments by the
> > procID as well.
>
> No, because the comment really belongs to the function and should go
> away only when the function does. But I'd vote for giving operators
> their own comments.
Here's the history, FWIW:
I implemented COMMENT ON for just TABLES and COLUMNS, like Oracle.
Bruce requested it for all objects
I extended for all objects - including databases (my bad) ;-)
Peter E. was rewriting psql and wanted the COMMENT on operators to
reflect a COMMENT on the underlying function
I submitted a patch to do that - I just do what I'm told ;-)
Mike Mascari
mascarm@mascari.com