Обсуждение: 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