Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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
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@postgresql.org)
To make changes to your subs
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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 a
Bruce Momjian 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?
> Can
Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, if you do 'make install' in the pg_upgrade directory, would it also
> > install the shared lib contrib? If not, it seems kind of complicated
> > from a user perspective. Can't we pass a 'make' down into a
> > subdirectory and have a separate Makefi
Bruce Momjian wrote:
Can't we pass a 'make' down into a
subdirectory and have a separate Makefile just run? pg_migrator had
this rule:
all install installdirs uninstall distprep clean distclean
maintainer-clean:
$(MAKE) -C src $@
$(MAKE) -C func $@
Bruce Momjian writes:
> Uh, if you do 'make install' in the pg_upgrade directory, would it also
> install the shared lib contrib? If not, it seems kind of complicated
> from a user perspective. Can't we pass a 'make' down into a
> subdirectory and have a separate Makefile just run?
No. You're
Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Alvaro Herrera 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
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
>
Andrew Dunstan writes:
> Tom Lane wrote:
>> Alvaro Herrera 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
> thi
Tom Lane wrote:
Alvaro Herrera 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 subdirector
Alvaro Herrera 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
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/so
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.
16 matches
Mail list logo
