Prev: multibyte charater set in levenshtein function
Next: [HACKERS] pg_dump should not try CREATE OR REPLACE LANGUAGE < 9.0
From: Alvaro Herrera on 12 May 2010 15:10 Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010: > We could try to make this a supported build arrangement, but I'm > inclined to think that a cleaner solution is to split out the loadable > module as a separate contrib subdirectory. Thoughts? Do you mean contrib/pg_upgrade/somelib? If so, +1. If you instead mean putting the library in contrib/somelib, I'm not so sure that it's cleaner than trying to support executable+shared lib in a single contrib module. -- -- 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 15:12 Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes: > Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010: >> We could try to make this a supported build arrangement, but I'm >> inclined to think that a cleaner solution is to split out the loadable >> module as a separate contrib subdirectory. Thoughts? > Do you mean contrib/pg_upgrade/somelib? If so, +1. Hmm. I had been thinking the other way, but I'll see if that can be made to work. 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: Andrew Dunstan on 12 May 2010 15:21 Tom Lane wrote: > Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes: > >> Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010: >> >>> We could try to make this a supported build arrangement, but I'm >>> inclined to think that a cleaner solution is to split out the loadable >>> module as a separate contrib subdirectory. Thoughts? >>> > > >> Do you mean contrib/pg_upgrade/somelib? If so, +1. >> > > Hmm. I had been thinking the other way, but I'll see if that can be > made to work. > > > Not sure this will work on its own with the MSVC build system - I don't think it's set up for sub-modules. But we can finessee that if necessary, just as we make special provision for pgcrypto. cheers andrew -- 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 15:30 Andrew Dunstan <andrew(a)dunslane.net> writes: > Tom Lane wrote: >> Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes: >>> Do you mean contrib/pg_upgrade/somelib? If so, +1. >> >> Hmm. I had been thinking the other way, but I'll see if that can be >> made to work. > Not sure this will work on its own with the MSVC build system - I don't > think it's set up for sub-modules. Oh, right. Since the entire point here is to *not* require new buildsystem infrastructure for pg_upgrade, I'm back to thinking that a separate contrib module is the way to go. 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 17:55
Tom Lane wrote: > A look at the MSVC buildfarm members shows that they are not building > most of the files added to contrib/pg_upgrade. The reason seems to be > that that module tries to build both an executable program *and* a > shared library, which it does by dint of setting both PROGRAM and > MODULES in its Makefile. Now that is a dirty hack that is nowhere > documented to work, and in fact the pgxs documentation explicitly says > not to do that. It accidentally fails to fail, at the moment, because > of the way pgxs.mk is set up, and because the OBJS variable is only > needed for one of these targets. But the MSVC build scripts aren't > expecting this and evidently disregard PROGRAM after they see MODULES. Yeah, I was stumped by the problem of creating an executable and shared object and didn't find any usage of this case. Leave it me to find a loop-hole. ;-) -- 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 |