[PATCHES] build infrastructure for extensions v3
Dear patchers, Please find attached version number 3 for a patch to enable extensions such as contribs or external add-ons to be installed simply with an already installed postgresql. This version addresses Peter's comments about src/makefiles/Makefile.* that do not need to be installed. It works for me, as previous versions. See other comments in previous submissions and responses. -- Fabien.*** ./GNUmakefile.in.orig Mon Jun 14 15:33:06 2004 --- ./GNUmakefile.inMon Jul 5 09:24:51 2004 *** *** 13,30 $(MAKE) -C src all @echo "All of PostgreSQL successfully made. Ready to install." ! install: $(MAKE) -C doc install $(MAKE) -C src install - @echo "PostgreSQL installation complete." ! installdirs uninstall distprep: $(MAKE) -C doc $@ $(MAKE) -C src $@ install-all-headers: $(MAKE) -C src $@ # clean, distclean, etc should apply to contrib too, even though # it's not built by default clean: --- 13,55 $(MAKE) -C src all @echo "All of PostgreSQL successfully made. Ready to install." ! install: light-install install-all-headers install-config-files ! @echo "PostgreSQL installation complete." ! ! light-install: $(MAKE) -C doc install $(MAKE) -C src install ! distprep: $(MAKE) -C doc $@ $(MAKE) -C src $@ + installdirs: + $(MAKE) -C doc $@ + $(MAKE) -C src $@ + $(MAKE) -C config $@ + $(mkinstalldirs) $(DESTDIR)$(pgxsdir) + + uninstall: + $(MAKE) -C doc $@ + $(MAKE) -C src $@ + $(MAKE) -C config $@ + $(DESTDIR)$(pgxsdir) + install-all-headers: $(MAKE) -C src $@ + install-config-files: installdirs + $(MAKE) -C src $@ + $(MAKE) -C config $@ + $(INSTALL_DATA) config.status $(DESTDIR)$(pgxsdir) + + install-client-only: + $(MAKE) -C src/bin install + $(MAKE) -C src/include install + $(MAKE) -C src/interfaces install + $(MAKE) -C doc install + # clean, distclean, etc should apply to contrib too, even though # it's not built by default clean: *** ./config/Makefile.orig Mon Jul 5 09:24:51 2004 --- ./config/Makefile Mon Jul 5 09:24:51 2004 *** *** 0 --- 1,19 + # $PostgreSQL$ + + subdir = config + top_builddir = .. + include $(top_builddir)/src/Makefile.global + + ins_files = install-sh mkinstalldirs + ins_dir = $(DESTDIR)$(pgxsdir)/config + + install-config-files: install + + install: installdirs + for f in $(ins_files) ; do $(INSTALL_DATA) $$f $(ins_dir) ; done; + + installdirs: + $(mkinstalldirs) $(ins_dir) + + uninstall: + for f in $(ins_files) ; do $(RM) $(ins_dir)/$$f ; done; *** ./contrib/btree_gist/pgxs.mk.orig Mon Jul 5 09:24:51 2004 --- ./contrib/btree_gist/pgxs.mkMon Jul 5 09:24:51 2004 *** *** 0 --- 1,28 + # local configuration + MODULE_big = btree_gist + OBJS= btree_common.o btree_int2.o btree_int4.o btree_int8.o btree_float4.o btree_float8.o btree_ts.o + DATA_built = btree_gist.sql + DOCS = README.btree_gist + REGRESS = btree_gist + + EXTRA_CLEAN = btree_int2.c btree_int4.c btree_int8.c btree_float4.c btree_float8.c + + # generic settings + PGXS := $(shell pg_config --pgxs) + include $(PGXS) + + # local rules + btree_int2.c: btree_num.c.in + sed 's,__DEFINE_BTREE_TYPE_HERE__,BTREE_GIST_INT2,g;s,__BTREE_GIST_TYPE__,int16,g;s,__BTREE_GIST_TYPE2__,int2,g' < $< > $@ + + btree_int4.c: btree_num.c.in + sed 's,__DEFINE_BTREE_TYPE_HERE__,BTREE_GIST_INT4,g;s,__BTREE_GIST_TYPE__,int32,g;s,__BTREE_GIST_TYPE2__,int4,g' < $< > $@ + + btree_int8.c: btree_num.c.in + sed 's,__DEFINE_BTREE_TYPE_HERE__,BTREE_GIST_INT8,g;s,__BTREE_GIST_TYPE__,int64,g;s,__BTREE_GIST_TYPE2__,int8,g' < $< > $@ + + btree_float4.c: btree_num.c.in + sed 's,__DEFINE_BTREE_TYPE_HERE__,BTREE_GIST_FLOAT4,g;s,__BTREE_GIST_TYPE__,float4,g;s,__BTREE_GIST_TYPE2__,float4,g' < $< > $@ + + btree_float8.c: btree_num.c.in + sed 's,__DEFINE_BTREE_TYPE_HERE__,BTREE_GIST_FLOAT8,g;s,__BTREE_GIST_TYPE__,float8,g;s,__BTREE_GIST_TYPE2__,float8,g' < $< > $@ *** ./contrib/chkpass/pgxs.mk.orig Mon Jul 5 09:24:51 2004 --- ./contrib/chkpass/pgxs.mk Mon Jul 5 09:24:51 2004 *** *** 0 --- 1,12 + # local conf + MODULE_big = chkpass + OBJS = chkpass.o + SHLIB_LINK = $(filter -lcrypt, $(LIBS)) + DATA_built = chkpass.sql + DOCS = README.chkpass + + # global + PGXS := $(shell pg_config --pgxs) + include $(PGXS) + + # local rules *** ./contrib/cube/pgxs.mk.orig Mon Jul 5 09:24:51 2004 --- ./contrib/cube/pgxs.mk Mon Jul 5 09:24:51 2004 *** *** 0 --- 1,35 + # generic macros + MODULE_big = cube + OBJS= cube.o cubeparse.o + + DATA_built = cube.sql + DOCS = README.cube + REGRESS = cube + + EXTRA_CLEAN = cubeparse.c cubeparse.h cubescan.c y.tab.c y.tab.h + + # postgresql extension
Re: [PATCHES] Show encoding in initdb messages
Is this a TODO? --- Andrew Dunstan wrote: > Tom Lane wrote: > > >Peter Eisentraut <[EMAIL PROTECTED]> writes: > > > > > >>But the answer space is infinite: > >> > >> > > > > > > > >>$ LANG=C locale charmap > >>ANSI_X3.4-1968 > >> > >> > > > >Right, the hard part is mapping whatever weird string "locale charmap" > >chooses to return into one of the encodings our code knows about. > > > >HPUX seems to be just arbitrarily bizarre: > > > >$ LC_ALL=en_US.iso88591 locale charmap > >"iso88591.cm" > >$ LC_ALL=C.utf8 locale charmap > >"utf8.cm" > >$ > > > >As near as I can tell, the .cm is present in all the possible results; > >and why the quotes? > > > > > > > > > > > >>I suspect Japanese users will also have a problem with this mechanism, > >>but at least we could keep -E to override the automatic selection. > >> > >> > > > >Perhaps we could try to derive a setting from locale charmap, but barf > >and require explicit -E if we can't recognize it? > > > > > > > > Sounds like an excellent plan, at least for platforms that have such a > command. Windows does not appear to :-(. Are there other *nixes that > also lack it, or that also produce bizarre results like PH-UX? > > cheers > > andrew > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] make_ctags change
Applied by Tom. --- Gavin Sherry wrote: > Exuberant ctags adds data at the beginning of the tags file. It also sorts > the tags file by default. This means, if we sort the file generated by > Exuberant ctags, it doesn't work in VIM and possibly other editors. > > I didn't notice this until recently because I was using my own script. Its > possible that this only affects recent version of Exuberant ctags though I > tested a version from 2001 which exhibited the same behaviour. > > Gavin Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Digital Mars C++ - Clients
Uh, I have never heard of Digital Mars C++. I see it here though: http://www.digitalmars.com/ Having never had anyone who uses it, it seems this patch would be better kept where users of digital Mars could find it, like on their ftp server. I don't think there enough usage of Digital Mars for us to adjust our source code at this time. Do you agree? --- Hans Oesterholt-Dijkema wrote: > L.S., > > I've made a patch against PostgreSQL 7.4.3 to be able to > compile 'libpq'? and 'psql'? with Digital Mars C++. > > As Digital Mars C++ doesn't support 'popen()' and 'pclose()' > calls yet, I was in need to patch some psql .c files to let > them work well with the Digital Mars C++ port. > > One can apply the patch doing: > > ??? tar xzf postgresql-7.4.3.tar.gz > ??? cd postgresql-7.4.3 > ??? patch -p1 > Maybe someone can put this patch in the postgresql source > distribution somewhere? > > Best whishes, > -- > Hans Dijkema > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] serverlog rotation/functions
Andreas Pflug <[EMAIL PROTECTED]> writes: > The attached patch includes serverlog rotation with minimal shared > memory usage as discussed and functions to access it. This patch is still unsafe and unworkable. Why would you make the mechanism dependent on shared memory *and* an intermediate data file *and* an inherited file handle to access that data file? The inherited handle is subject to race conditions (because you've got different processes fseeking the same file descriptor with no interlocking) and I don't really see that it's buying anything anyway. If you stored the value of time(NULL) to use in shared memory, you'd not need the data file because every process could compute the correct logfile name for itself. An issue that doesn't matter a whole lot on Unix, but I think would matter on Windows, is that with the patch as given a process will not reopen the log file until it's got something to write there. Non-chatty processes could easily hold open the old log file indefinitely. It might be a good idea to force the log file to be reopened at SIGHUP, and for the "rotate" command to do such a SIGHUP. Overall though, I still quite fail to see the point of doing it this way compared to piping the postmaster's stderr into something that can rotate log files. The fundamental objection to this whole feature is that it can only capture elog output, which is not everything of interest. (For example, dynamic linker failures will usually be reported to stderr, a behavior that we cannot override.) regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] bug in GUC
Thomas Hallgren <[EMAIL PROTECTED]> writes: > Here's a patch dealing with the unchecked mallocs and strdups in guc.c. Applied with minor editorialization. Thanks. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] actualized czech FAQ
Pavel Stehule wrote: > Hello hackers > > I actualized and reformated czech FAQ. diff and full text are in > attachments. > > changes: common look like others FAQ, repair some formating errors, > accepting last changes in english FAQ Uh, I hate to say this, but the source for the czech FAQ is in HTML in doc/src/FAQ. Would you send me a context diff against that file? Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend