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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers