Thread: New ALTER OPERATOR command fails to update dependencies
I noticed $subject while chasing a different issue. The way to fix this is to export pg_operator.c's makeOperatorDependencies function so that AlterOperator can call it. But since that declaration uses HeapTuple, I doubt we want to put it into pg_operator.h (which'd require further growth in that file's include list, and possibly break client-side code that wants to #include it). I'm inclined to split out pg_operator.h's function declarations into a new header pg_operator_fn.h, as we've already done in related cases. While this isn't exactly a stop-ship class of problem, it still seems like it'd be good to fix before 9.5.0. Any objections? regards, tom lane
Tom Lane wrote: > I noticed $subject while chasing a different issue. > > The way to fix this is to export pg_operator.c's makeOperatorDependencies > function so that AlterOperator can call it. But since that declaration > uses HeapTuple, I doubt we want to put it into pg_operator.h (which'd > require further growth in that file's include list, and possibly break > client-side code that wants to #include it). I'm inclined to split out > pg_operator.h's function declarations into a new header pg_operator_fn.h, > as we've already done in related cases. Hmm, yeah, pg_operator.h defines a lot of operator OIDs. I think including htup.h wouldn't be terribly problematic nowadays, actually. But I can get behind a plan to move CreateOperator to the new file as well, and get rid of objectaddress.h and pglist.h from pg_operator.h. > While this isn't exactly a stop-ship class of problem, it still seems like > it'd be good to fix before 9.5.0. I wonder if a note to packagers to inform them of the new file added after the RC would be a good idea. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Tom Lane wrote: >> While this isn't exactly a stop-ship class of problem, it still seems like >> it'd be good to fix before 9.5.0. > I wonder if a note to packagers to inform them of the new file added > after the RC would be a good idea. I doubt they care; I've not seen any packaging recipes that try to enumerate every single .h file. The maintenance would be too painful. regards, tom lane
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Tom Lane wrote: >> While this isn't exactly a stop-ship class of problem, it still seems like >> it'd be good to fix before 9.5.0. > I wonder if a note to packagers to inform them of the new file added > after the RC would be a good idea. On closer look, the busted ALTER OPERATOR functionality is only in HEAD anyway. But having said that, I wonder whether we ought not backpatch the header file splitup anyhow. I observe that pg_operator.h's inclusion of objectaddress.h is new in 9.5, and it sure looks to me like objectaddress.h would be problematic for clients to include. So if we don't do this, we might well get reports of client build failures. (pg_operator.h is not the only catalog header that includes objectaddress.h now, but it's the only one that does that and seems like a plausible file for clients to include.) regards, tom lane