Build pg_failover_slots from inside the contrib folder (without reading pg_config) about pg_failover_slots

[petere]

Why would you want that?

[ashucoek]

We want to build the extension without pg_config binary. It would be similar to how other extensions can be built both with and without pg_config binary.

[petere]

We want to build the extension without pg_config binary.

And why would you want that?

[ashucoek]

We've added pg_failover_slots into the contrib folder and we want to make it a part of our overall PG source code build.

[petere]

I don't know who "we" is in this case, but if you are making your own PostgreSQL distribution with custom changes, can't you also make your own custom changes to the build specifications? Presumably, you'd need to update contrib/Makefile or similar anyway.

[ashucoek]

By we, I meant our team, anyway, the point is - I am not making any changes to the extension, it is just that like I/ we build other extensions in the contrib folder, I want this extension as well to be build in the similar way.

[mwanner]

That boils down to: you want to change the extension without changing the extension. It just doesn't make sense.

[ashucoek]

OK. Let me clarify the point that I'm trying to make here - by not changing the extension, I meant not making any changes to the the source code (.c file). I just want the extension to be built without pg_config binary like we have for other extensions (present in the contrib folder) and that just requires changes in the Makefile not any .c file or any other file. In short, this is about making changes to the Makefile so that users can build the extension without pg_config binary.

[rjuju]

I think that @ashucoek asks for something sensible. After all postgres' contrib/contrib-global.mk adds a "NO_PGXS=1", isn't it done exactly to allow people to put any extension there and have them compile it easily with the rest of the contribs without having to fork the extension too?

It doesn't cost much to add the same PG_CONFIG / top_buildir instructions as the contribs and many third-party extensions. You can even make PGXS be used by default (ie. using ifndef NO_PGXS rather than ifdef USE_PGXS) so that it doesn't impact you at all.

[mwanner]

I think that @ashucoek asks for something sensible. After all postgres' contrib/contrib-global.mk adds a "NO_PGXS=1", isn't it done exactly to allow people to put any extension there and have them compile it easily with the rest of the contribs without having to fork the extension too?

No. The reason for that is for core to be able to ship a few extensions via contrib. That doesn't mean to indicate this is a good approach for out-of-core extensions. Actually, the reason for to extension framework and PGXS to exist is to not need to have them it the PG source tree. So I'd argue that's an obviously bad place of where to put 3rd party extensions.

It doesn't cost much to add the same PG_CONFIG / top_buildir instructions as the contribs and many third-party extensions. You can even make PGXS be used by default (ie. using ifndef NO_PGXS rather than ifdef USE_PGXS) so that it doesn't impact you at all.

You admit there's some non-zero cost, but so far I have not spotted a single benefit.

[petere]

It doesn't cost much to add the same PG_CONFIG / top_buildir instructions as the contribs and many third-party extensions. You can even make PGXS be used by default (ie. using ifndef NO_PGXS rather than ifdef USE_PGXS) so that it doesn't impact you at all.

The cost is that someone needs to maintain and test it. This is not trivial. Consider for example 783d6b5. This change would have added another dimension to testing that.

[ashucoek]

thanks everyone for your thoughts/opinion.