Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
