Bruce Momjian wrote:
> 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.
FYI, to be more explicit, with the pgFoundry code, I didn't know what
target major PG version I would be linking to, so I needed different
shared object files because there were some symbols that would only
resolve to specific backend versions. I would probe the target major
version and link in the matching shared object file. This was
particularly common for Win32 binaries.
That is no longer an issue with /contrib.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
