pg_upgrade versus MSVC build scripts
in [PgSql]
|
Prev: multibyte charater set in levenshtein function
Next: [HACKERS] pg_dump should not try CREATE OR REPLACE LANGUAGE < 9.0
From: Bruce Momjian on 12 May 2010 18:49 Tom Lane wrote: > Bruce Momjian <bruce(a)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(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 12 May 2010 19:02 Bruce Momjian <bruce(a)momjian.us> writes: > 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. +1 for pg_upgrade_tools or pg_upgrade_support or some such name. > 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. It has to be directly under /contrib, because the MSVC build scripts only look there for contrib modules to build. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 12 May 2010 19:07 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > 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. > > +1 for pg_upgrade_tools or pg_upgrade_support or some such name. I like 'pg_upgrade_support'. I could also do 'pg_upgrade_funcs'. > > 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. > > It has to be directly under /contrib, because the MSVC build scripts > only look there for contrib modules to build. OK. Should I get started? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 12 May 2010 19:11 On May 12, 2010, at 4:07 PM, Bruce Momjian wrote: > I like 'pg_upgrade_support'. I could also do 'pg_upgrade_funcs'. I misread the second one at a glance, so I recommend the first. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 12 May 2010 19:55
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <bruce(a)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(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |