Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > If we make it /contrib/pg_upgrade_shlibs, will it need a documentation
> > page?
>
> I don't see a need for that. Also, why would you make the directory
> name different from the name of the shlib it's building --- or are
> you having second thoughts about the present name?
Well, previously I needed separate shared objects because I didn't know
what _new_ backend version I would be linking to and the symbols could
be different. I actually dynamically linked in different SO's for
different major versions.
Now that it only targets the packaged version, I can do with a single
shared object, but maybe it needs to be more generic, like
pg_upgrade_tools.so or something like that.
> > Can I built multiple shared libs in there if needed?
>
> No, but why would you need more than one? What you might need
> (and can't have with the present hack) is more than one .o file
> getting built into the shared library.
Again, I used to need this, but I don't now.
> > If we put
> > it under /contrib/pg_upgrade, can it still be a separate build step?
> > Would that work?
>
> Isn't that the same idea you just proposed?
I realize we need a separate pgxs makefile for the executable and shared
libraries. My question was whether the shared library directory should
be under /contrib or under /contrib/pg_upgrade.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com