Tom Lane wrote: > > "Rod Taylor" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
