Re: [PATCHES] new aggregate functions v3
Fabien COELHO wrote: (1) boolean-and and boolean-or aggregates named bool_and and bool_or. they (SHOULD;-) correspond to standard sql every and some/any aggregates. they do not have the right name as there is a problem with the standard and the parser for some/any. Tom also think that the standard name is misleading because NULL are ignored. As I understand it, there's an ambiguity issue with SOME/ANY, but not with EVERY. If so, can we implement EVERY per-spec at least? It's okay if we just add EVERY as an alias for BOOL_AND for the sake of homogeneity. A few trivial points: + /* EVERY aggregate implementation conforming to SQL 2003 standard. + * must be strict. + */ This comment is misleading if we don't actually provide an implementation of EVERY that conforms to spec. There's a similar comment WRT to SOME/ANY. + PG_FUNCTION_INFO_V1(booland_statefunc); Not needed for builtin functions (they are assumed to be V1). + /* what about every? */ + DATA(insert OID = 2517 ( bool_andPGNSP PGUID 12 t f f f i 1 16 16 _null_ aggregate_dummy - _null_ )); + DESCR(boolean-and aggregate); + /* what about any/some? */ Seems these questions should be removed, no? -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] add build utilities in default install
Dear Tom,
Please find attached my first submission for installing all necessary
build files (makefile, scripts...) by default.
Why? They won't do anyone any good outside the original build tree.
Is your question rhetorical?
So as to allow postgresql extensions (types, functions) to be compiled as
if they would have been compiled in the source tree, as contribs.
Even if modified so that they are useful (which is something that is
on my to-do list),
I agree that it is not simple to make them usable as is.
I'm trying to have a minimum effort solution, but I would be interested in
having a better one, esp. if I don't have to do it myself.
I disagree with installing them by default. See previous arguments about
installing backend internal headers by default.
http://archives.postgresql.org: Can not connect to search daemon
well, my look at previous archived arguments will wait.
Anyway, you both forbid extensions to be added within the main
distribution, and to provide help for these extensions to be added from
the outside.
So instead of saying no, please help us solve the problem: how to make
extensions easilly installable against a postgresql, preferably with
minimum effort from the user who would like to try that?
Under apache, I just do : apxs -c -i -a mod_foo.c and it is enough.
If your solution is that extensions should require the sysadmin to fetch
postgresql sources and reconfigure... I disagree. If you have something
better, I'm all ears.
--
Fabien COELHO _ http://www.cri.ensmp.fr/~coelho _ [EMAIL PROTECTED]
CRI-ENSMP, 35, rue Saint-Honoré, 77305 Fontainebleau cedex, France
phone: (+33|0) 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08}
All opinions expressed here are mine _
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] new aggregate functions v4
Dear Bruce,
Agreed, these seem to be of general interest and have been requested in
the past. I will clean up the docs a little.
Please find attached a new version to address Neil's comments.
- add every anyway, next to bool_and.
- cleaner source and comments.
I also added more regression tests, including the added EVERY aggregate.
It DOES NOT validate for me, as errors and rules are broken in current
head:
undefined symbol: pg_strcasecmp
However the aggregate part works fine.
Have a nice day,
--
Fabien Coelho - [EMAIL PROTECTED]*** ./doc/src/sgml/func.sgml.orig Mon May 17 14:00:06 2004
--- ./doc/src/sgml/func.sgmlWed May 19 10:27:17 2004
***
*** 7554,7559
--- 7554,7629
/row
row
+ entry
+indexterm
+ primarybit_and/primary
+/indexterm
+functionbit_and(replaceable
class=parameterexpression/replaceable)/function
+ /entry
+ entry
+typesmallint/type, typeinteger/type, typebigint/type or
+typebit/type,
+ /entry
+ entry
+ same as argument data type.
+ /entry
+ entrythe bitwise-and of all non-null input values, or null if empty
+ /entry
+ /row
+
+ row
+ entry
+indexterm
+ primarybit_or/primary
+/indexterm
+functionbit_or(replaceable
class=parameterexpression/replaceable)/function
+ /entry
+ entry
+typesmallint/type, typeinteger/type, typebigint/type or
+typebit/type,
+ /entry
+ entry
+ same as argument data type.
+ /entry
+ entrythe bitwise-or of all non-null input values, or null if empty.
+ /entry
+ /row
+
+ row
+ entry
+indexterm
+ primarybool_and/primary
+/indexterm
+functionbool_and(replaceable
class=parameterexpression/replaceable)/function
+ /entry
+ entry
+typebool/type
+ /entry
+ entry
+typebool/type
+ /entry
+ entrytrue if all input values are true, otherwise false.
+ Also known as functionbool_and/function.
+ /entry
+ /row
+
+ row
+ entry
+indexterm
+ primarybool_or/primary
+/indexterm
+functionbool_or(replaceable
class=parameterexpression/replaceable)/function
+ /entry
+ entry
+typebool/type
+ /entry
+ entry
+typebool/type
+ /entry
+ entrytrue if at least one input value is true, otherwise false/entry
+ /row
+
+ row
entryfunctioncount(*)/function/entry
entry/entry
entrytypebigint/type/entry
***
*** 7571,7576
--- 7641,7664
/row
row
+ entry
+indexterm
+ primaryevery/primary
+/indexterm
+functionevery(replaceable
class=parameterexpression/replaceable)/function
+ /entry
+ entry
+typebool/type
+ /entry
+ entry
+typebool/type
+ /entry
+ entrytrue if all input values are true, otherwise false.
+ Also known as functionbool_and/function.
+ /entry
+ /row
+
+ row
entryfunctionmax(replaceable
class=parameterexpression/replaceable)/function/entry
entryany numeric, string, or date/time type/entry
entrysame as argument type/entry
***
*** 7661,7666
--- 7749,
/para
note
+ indexterm
+ primaryANY/primary
+ /indexterm
+ indexterm
+ primarySOME/primary
+ /indexterm
+ para
+ Boolean aggregates functionbool_and/function and
+ functionbool_or/function correspond to standard SQL aggregates
+ functionevery/function and functionany/function or
+ functionsome/function.
+ As for functionany/function and functionsome/function,
+ it seems that there is an ambiguity built into the standard syntax:
+ programlisting
+ SELECT b1 = ANY((SELECT b2 FROM t2 ...)) FROM t1 ...;
+ /programlisting
+ Here functionANY/function can be considered both as leading
+ to a subquery or as an aggregate if the select expression returns 1 row.
+ Thus the standard name cannot be given to these aggregates.
+ /para
+ /note
+
+ note
para
Users accustomed to working with other SQL database management
systems may be surprised by the performance characteristics of
*** ./src/backend/utils/adt/bool.c.orig Mon May 17 14:00:09 2004
--- ./src/backend/utils/adt/bool.c Wed May 19 10:18:13 2004
***
*** 248,250
--- 248,270
PG_RETURN_BOOL(b);
}
+
+ /*
+ * boolean-and and boolean-or aggregates.
+ */
+
+ /* function for standard EVERY aggregate implementation conforming to SQL 2003.
+ * must be strict. It is also named bool_and for homogeneity.
+ */
+ Datum booland_statefunc(PG_FUNCTION_ARGS)
+ {
+ PG_RETURN_BOOL(PG_GETARG_BOOL(0) PG_GETARG_BOOL(1));
+ }
+
+ /*
Re: [PATCHES] new aggregate functions v1
Bruce Momjian [EMAIL PROTECTED] writes: I will try to apply it within the next 48 hours. This patch seems to still be under active discussion. Would you refrain from giving the impression that it's going to be applied as-is? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] new aggregate functions v1
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I will try to apply it within the next 48 hours. This patch seems to still be under active discussion. Would you refrain from giving the impression that it's going to be applied as-is? He submitted a new version based on Neil's comments, and barring any other comments, it will be applied in 24-48 hours. I haven't seen anything that would meke that conclusion invalid. -- 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] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p ...
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: [EMAIL PROTECTED] (Bruce Momjian) writes: Remove elog() calls from find_my_exec; do fprintf(stderr) instead. Isn't that a seriously bad idea? Yes, it probably is bad, but I am not sure how frequently this will happen, _and_ I need to set my_exec_path very far up in the tree to the timezone stuff knows the location, hence the fact that elog() calls wouldn't work at all anyway, I think. The more I think about this, the less I like it. find_my_exec and friends are *not* more critical to the backend than elog is, and should not be done sooner. The argument that we have to find postgresql.conf before elog works is specious --- elog will work fine before we have read the config file, indeed had better do so since guc.c uses elog to report problems. What will happen is that errors will get reported to the compiled-in-default location, which happens to be stderr at the moment. All you are accomplishing with this change is to hard-wire that default and make it impossible to change in the future. Sure, I didn't know elog() sent to stderr before it was initialized. The following patch uses elog() when linked to the backend, and stderr directly when used by client code. The old code was really DEBUG2-level stuff (it showed how it was searching the PATH mostly), but I have remove those because for clients that is going to go to stderr, so now it only does an elog(LOG) when something significant happens. I did have to re-add the separate compile of exec.c to every place that used it because clients don't have elog, but that's OK. Other concerns: I do not like changing random error reports from elog to printf, firstly because it will encourage people to code other error reports as printfs, which is something that took us a huge amount of work to stamp out, and secondly because the requirement will propagate. Are you going to avoid using palloc in find_my_exec, too? What about in any subroutines that these things call? I recommend reverting both this change and the ones to do find_my_exec etc in main.c. You're better off doing these things where they were done in PostmasterMain, PostgresMain, etc. palloc and elog are simply fundamental parts of the backend programming environment; it does not make sense to push complex functionality into a part of the code where they aren't available. In the old code, the exec path was only used for dynamic linking for platforms that needed a full path for dynamic linking. Now the timezone code and even the $libdir path (used by GUC) is set from my_exec_path, so it has to be earlier. I can put it much earlier in both postgres and postmaster, but by having it in main.c, I have it in only one place. It doesn't do any palloc or anything fancy, because of course it is also used by client apps. Patch attached and applied. -- 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 Index: src/bin/initdb/Makefile === RCS file: /cvsroot/pgsql-server/src/bin/initdb/Makefile,v retrieving revision 1.39 diff -c -c -r1.39 Makefile *** src/bin/initdb/Makefile 18 May 2004 20:18:58 - 1.39 --- src/bin/initdb/Makefile 19 May 2004 17:12:59 - *** *** 15,27 override CPPFLAGS := -DFRONTEND -I$(libpq_srcdir) $(CPPFLAGS) ! OBJS= initdb.o all: submake-libpq submake-libpgport initdb initdb: $(OBJS) $(libpq_builddir)/libpq.a $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o [EMAIL PROTECTED](X) install: all installdirs $(INSTALL_PROGRAM) initdb$(X) $(DESTDIR)$(bindir)/initdb$(X) --- 15,31 override CPPFLAGS := -DFRONTEND -I$(libpq_srcdir) $(CPPFLAGS) ! OBJS= initdb.o \ ! $(filter exec.o, $(LIBOBJS)) all: submake-libpq submake-libpgport initdb initdb: $(OBJS) $(libpq_builddir)/libpq.a $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o [EMAIL PROTECTED](X) + exec.c: % : $(top_srcdir)/src/port/% + rm -f $@ $(LN_S) $ . + install: all installdirs $(INSTALL_PROGRAM) initdb$(X) $(DESTDIR)$(bindir)/initdb$(X) *** *** 32,38 rm -f $(DESTDIR)$(bindir)/initdb$(X) clean distclean maintainer-clean: ! rm -f initdb$(X) $(OBJS) # ensure that changes in datadir propagate into object file --- 36,42 rm -f $(DESTDIR)$(bindir)/initdb$(X) clean distclean maintainer-clean: ! rm -f initdb$(X) $(OBJS) exec.c # ensure that changes in datadir propagate into object file Index: src/bin/pg_dump/Makefile === RCS file: /cvsroot/pgsql-server/src/bin/pg_dump/Makefile,v
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p ...
Bruce Momjian [EMAIL PROTECTED] writes: so it has to be earlier. I can put it much earlier in both postgres and postmaster, but by having it in main.c, I have it in only one place. It doesn't do any palloc or anything fancy, because of course it is also used by client apps. Patch attached and applied. And tested? I didn't say that I thought elog would work in main.c. In fact I'm pretty certain it won't. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p ...
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: so it has to be earlier. I can put it much earlier in both postgres and postmaster, but by having it in main.c, I have it in only one place. It doesn't do any palloc or anything fancy, because of course it is also used by client apps. Patch attached and applied. And tested? I didn't say that I thought elog would work in main.c. In fact I'm pretty certain it won't. Compiles/regression tests pass. This is why I removed elog in the first place, because I thought it wouldn't work up higher before the guc load, but you said it would use the default. Are you saying it only works after guc is loaded? Seems we have a chicken and egg thing here. I think the guc load needs the default timezone, and for that we need the exec path so we can find share. So, what do you want with the code? -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p ...
so it has to be earlier. I can put it much earlier in both postgres and postmaster, but by having it in main.c, I have it in only one place. It doesn't do any palloc or anything fancy, because of course it is also used by client apps. Patch attached and applied. And tested? I didn't say that I thought elog would work in main.c. In fact I'm pretty certain it won't. Compiles/regression tests pass. This is why I removed elog in the first place, because I thought it wouldn't work up higher before the guc load, but you said it would use the default. Are you saying it only works after guc is loaded? Seems we have a chicken and egg thing here. I think the guc load needs the default timezone, and for that we need the exec path so we can find share. No for the timezone. GUC loads first, then the default timezone is set only if one is not explicitly set in GUC (this is with the not-yet-applied code coming up). //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p ...
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: And tested? I didn't say that I thought elog would work in main.c. In fact I'm pretty certain it won't. Compiles/regression tests pass. You need to test the cases that will produce elog output. This is why I removed elog in the first place, because I thought it wouldn't work up higher before the guc load, but you said it would use the default. Are you saying it only works after guc is loaded? No, I specifically said it didn't need guc. But it does need palloc, which means MemoryContextInit() has to run first. I could see running find_my_exec immediately before InitializeGUCOptions() in PostmasterMain. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: And tested? I didn't say that I thought elog would work in main.c. In fact I'm pretty certain it won't. Compiles/regression tests pass. You need to test the cases that will produce elog output. This is why I removed elog in the first place, because I thought it wouldn't work up higher before the guc load, but you said it would use the default. Are you saying it only works after guc is loaded? No, I specifically said it didn't need guc. But it does need palloc, which means MemoryContextInit() has to run first. I could see running find_my_exec immediately before InitializeGUCOptions() in PostmasterMain. OK, I moved the find_my_exec calls to the locations you mentioned in both postgres.c and postmaster.c and remove it from main.c. I tested the elog and it worked. -- 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 ? log ? config.log ? GNUmakefile ? config.status ? src/Makefile.global ? src/Makefile.custom ? src/log ? src/backend/postgres ? src/backend/catalog/postgres.bki ? src/backend/catalog/postgres.description ? src/backend/utils/mb/conversion_procs/conversion_create.sql ? src/backend/utils/mb/conversion_procs/ascii_and_mic/libascii_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/libcyrillic_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/libeuc_cn_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/liblatin2_and_win1250.so.0.0 ? src/backend/utils/mb/conversion_procs/latin_and_mic/liblatin_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/libutf8_and_ascii.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_big5/libutf8_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/libutf8_and_cyrillic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/libutf8_and_euc_cn.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/libutf8_and_euc_jp.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/libutf8_and_euc_kr.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/libutf8_and_euc_tw.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/libutf8_and_gb18030.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/libutf8_and_gbk.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/libutf8_and_iso8859.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/libutf8_and_iso8859_1.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_johab/libutf8_and_johab.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_sjis/libutf8_and_sjis.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_tcvn/libutf8_and_tcvn.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_uhc/libutf8_and_uhc.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win1250/libutf8_and_win1250.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win1256/libutf8_and_win1256.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win874/libutf8_and_win874.so.0.0 ? src/bin/initdb/initdb ? src/bin/initlocation/initlocation ? src/bin/ipcclean/ipcclean ? src/bin/pg_config/pg_config ? src/bin/pg_controldata/pg_controldata ? src/bin/pg_ctl/pg_ctl ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_restore ? src/bin/pg_dump/pg_dumpall ? src/bin/pg_resetxlog/pg_resetxlog ? src/bin/psql/psql ? src/bin/scripts/createdb ? src/bin/scripts/createlang ? src/bin/scripts/createuser ? src/bin/scripts/dropdb ? src/bin/scripts/droplang ? src/bin/scripts/dropuser ? src/bin/scripts/clusterdb ? src/bin/scripts/vacuumdb ? src/include/pg_config.h ? src/include/stamp-h ? src/interfaces/ecpg/compatlib/libecpg_compat.so.1.1 ? src/interfaces/ecpg/ecpglib/libecpg.so.4.2 ? src/interfaces/ecpg/pgtypeslib/libpgtypes.so.1.2 ? src/interfaces/ecpg/preproc/ecpg ? src/interfaces/libpq/libpq.so.3.2 ? src/pl/plperl/SPI.c ? src/pl/plperl/libplperl.so.0.0 ? src/pl/plpgsql/src/libplpgsql.so.1.0 ? src/pl/tcl/libpltcl.so.2.0 ? src/pl/tcl/modules/pltcl_loadmod ? src/pl/tcl/modules/pltcl_delmod ? src/pl/tcl/modules/pltcl_listmod ? src/test/regress/pg_regress ? src/test/regress/log ? src/test/regress/results ? src/test/regress/expected/copy.out ? src/test/regress/expected/create_function_1.out ? src/test/regress/expected/create_function_2.out ? src/test/regress/expected/misc.out ? src/test/regress/expected/constraints.out ? src/test/regress/sql/copy.sql ? src/test/regress/sql/create_function_1.sql ? src/test/regress/sql/create_function_2.sql ?
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I moved the find_my_exec calls to the locations you mentioned in
both postgres.c and postmaster.c and remove it from main.c. I tested
the elog and it worked.
You omitted get_pkglib_path() from the postmaster case; was that
intentional?
Got it later. Thanks.
Also, in the non-exec case it seems unnecessary and possibly unsafe to
repeat this computation in a backend. It should inherit the settings
from the postmaster via fork(), I'd think. So possibly
#ifndef EXEC_BACKEND
if (!IsUnderPostmaster)
#endif
{
find_my_exec(...);
get_pkglib_path(...);
}
Thanks. It originally was as below and I forgot about that. It now is:
if (my_exec_path[0] == '\0' find_my_exec(argv[0], my_exec_path) 0)
The issue is that fork/exec will need to set it too.
--
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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] pg_dump end comment
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: This might seem a bit silly, but is there any chance we could add a comment at the end of pg_dump text output that says '-- End of dump'? Sure --- while you're at it, put a beginning of dump at the start. Is it worth adding the database name and/or other command-line parameters given to pg_dump? One thing to think about is the difference between a bare pg_dump and a pg_dump/pg_restore sequence. Should these always generate identical text output? (They do as of CVS tip, I believe, though this was not always true before.) I have added code to print end-of-dump markers for pg_dump and pg_dumpall: -- -- PostgreSQL database dump complete -- -- -- PostgreSQL database cluster dump complete -- This mirrors the markers used at the start of the files. -- 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 Index: src/bin/pg_dump/pg_backup_archiver.c === RCS file: /cvsroot/pgsql-server/src/bin/pg_dump/pg_backup_archiver.c,v retrieving revision 1.86 diff -c -c -r1.86 pg_backup_archiver.c *** src/bin/pg_dump/pg_backup_archiver.c22 Apr 2004 02:39:10 - 1.86 --- src/bin/pg_dump/pg_backup_archiver.c19 May 2004 21:17:43 - *** *** 384,389 --- 384,391 AH-blobConnection = NULL; } } + + ahprintf(AH, --\n-- PostgreSQL database dump complete\n--\n\n); } /* Index: src/bin/pg_dump/pg_dumpall.c === RCS file: /cvsroot/pgsql-server/src/bin/pg_dump/pg_dumpall.c,v retrieving revision 1.33 diff -c -c -r1.33 pg_dumpall.c *** src/bin/pg_dump/pg_dumpall.c14 May 2004 17:04:47 - 1.33 --- src/bin/pg_dump/pg_dumpall.c19 May 2004 21:17:43 - *** *** 242,247 --- 242,252 } PQfinish(conn); + + printf(--\n); + printf(-- PostgreSQL database cluster dump complete\n); + printf(--\n\n); + exit(0); } ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [PORTS] Building PgSQL 7.4.2 on SGI Irix 6.19
I have made your configure-related changes for Irix, and renamed the port from irix5 to irix. Patch attached. For your other comments, would you please send a new version or diff against FAQ_IRIX. I am unsure how much of the current content to change. Thanks. --- David Turover wrote: note: gmake check had a few out-of-order errors like this: *** 1732,1739 | 6 | 6 | six | | 7 | 7 | seven | | 8 | 8 | eight | - | | | null | | | 0 | zero | (13 rows) --- 1732,1739 | 6 | 6 | six | | 7 | 7 | seven | | 8 | 8 | eight | | | 0 | zero | + | | | null | (13 rows) I'm not sure how serious a problem this is. My configureetc patches are at the end of this message. Installing PostGreSQL 7.4.2 on SGI Irix 6.19 Summary: (install dependencies) cp *.patch postgresql-7.4.2 cd postgresql-7.4.2 patch -p1 _pg_config_programs_m4.patch autoconf export PATH=/usr/freeware/bin:$PATH ./configure --with-whatever gmake gmake check Patches: Copy the patches you want (READ THE DESCRIPTIONS!) to the postgres source directory, install them and run autoconf to generate a new configure script: patch -p1 patchname.patch autoconf 1) The configure.in patch just squelches a bunch of warnings in the config.log. It's not necessary unless you think you'll run into errors you'll need to debug. 2) The config/programs.m4 patch adds -lcurses to the command line. If you don't use it, you'll get undefined symbol errors trying to compile with readline support. 3) The template/irix5 patch adds the commands to turn on threading. It is untested! Don't expect your server to work if you use this. Generic problems: Using zsh 3.0.8, configure will often quit at a random point in the middle of running, claiming it received a sigint. This is probably a bug in zsh. Try opening a new shell and re-running configure from there. Readline support: SGI Freeware's readline 4.3 package installs the libraries to the wrong directory. You will need to move the N32 (mips-3) readline libs from /usr/lib to /usr/lib32 or else the linker won't detect -lreadline. Use the file command to see what ABI the libraries are using. You will also need the programs.m4 patch to add -lcurses to the gcc command line, or else you will get errors like this: 189218:./conftest: rld: Error: unresolvable symbol in /usr/lib32/libreadline.so.4: tgetent Java support: You'll need to install Java and ant and ant's dependencies, which is a difficult and sparsely documented task in itself. SGI has a java inst package available for download, or you can grab the latest version from Sun. As for ant's dependencies, I just grabbed everything on Apache's website since the docs say ant needs just about all of them, sorted it all into one directory except for a few packages that were obviously standalone and unnecessary, moved this mess into java2 so I don't have to deal with setting classpath to two dozen different directories, set all the java PACKAGE_HOME variables to $JAVA_HOME, and prayed. It survives configure, but is otherwise not tested. Notes on java support: 1) (important): Make sure that ant.jar is the full one from the ant package, not a stripped-down version from one of its dependencies which depends upon ant. You need the real thing, otherwise you will get java.lang.InstantiationException: org.apache.tools.ant.Main 2) Ant takes upwards of a minute just to load itself. As far as I can tell, this is normal behaviour. configure may /seem/ hung on ant, but just be patient. Perl support: Irix has two versions of Perl. SGI uses perl 5.0 in the main tree, but the newer 5.6.1 is available from freeware. Perl 5.0's libs do not define EXTERN_C, causing gmake to break in src/pl/plperl/plperl.c. 5.6.1 has EXTERN_C defined, but 5.6.1's Dynaloader.a breaks on ./ldtmpa01Ns3/DynaLoader.a(DynaLoader.o).B: Error: Invalid format revision (WHIRL::0.31:) for intermediate compiler file Temporary Solution 1 (using perl 5.0): 1: export CFLAGS=-DEXTERN_C=extern $CFLAGS Temporary solution 2 (using perl 5.6.1) (theoretical, haven't tried): 1: Rebuild perl 5.6.1 from source, without -IPA 2: Copy over the Dynaloader.a 3: Put /usr/freeware/bin before /usr/sbin in path and export it before running configure. Easiest way, in zsh: export PATH=/usr/freeware/bin:$PATH 4: Add to your configure command: --with-libraries=/usr/freeware/lib/perl5/5.6.1/irix-n32/CORE/libperl.so --with-includes=/usr/freeware/lib/perl5/5.6.1/CORE Python support: As long as the freeware python packages do not install shared libraries, you
Re: [PATCHES] [PORTS] Building PgSQL 7.4.2 on SGI Irix 6.19
Bruce Momjian [EMAIL PROTECTED] writes: I have made your configure-related changes for Irix, Please revert the configure.in changes (the programs.m4 one may be ok). Adding port-specific code to configure.in in order to suppress warnings in config.log is the mark of someone who hasn't a clue what autoconf is used for. I also wonder whether the arbitrary reordering of the library probes won't break some other platforms where those libraries depend on others. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c backend/p
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Also, in the non-exec case it seems unnecessary and possibly unsafe to repeat this computation in a backend. Thanks. It originally was as below and I forgot about that. It now is: if (my_exec_path[0] == '\0' find_my_exec(argv[0], my_exec_path) 0) The issue is that fork/exec will need to set it too. That fixes it for my_exec_path, but what of the pkglib_path stuff? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c b ackend/p
Claudio Natoli wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Also, in the non-exec case it seems unnecessary and possibly unsafe to repeat this computation in a backend. Thanks. It originally was as below and I forgot about that. It now is: if (my_exec_path[0] == '\0' find_my_exec(argv[0], my_exec_path) 0) The issue is that fork/exec will need to set it too. That fixes it for my_exec_path, but what of the pkglib_path stuff? OK, I will fix that one, though it is a cheap call. There's also the possibility of adding it to read/write_backend_variables, just as we add other variables for fork/exec that we want the backends to inherit. In the exec case, the executable name is actually different from the postmaster, so passing it doesn't make sense. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c b ackend/p
Bruce Momjian [EMAIL PROTECTED] writes: Claudio Natoli wrote: There's also the possibility of adding it to read/write_backend_variables, just as we add other variables for fork/exec that we want the backends to inherit. In the exec case, the executable name is actually different from the postmaster, so passing it doesn't make sense. How much do we care? AFAIK we only really care about the directory part of the path, no? There are ports that need the exact executable pathname for dynamic loading purposes, but I'd think Windows is not one of them. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [COMMITTERS] pgsql-server/src backend/main/main.c b ackend/p
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Claudio Natoli wrote: There's also the possibility of adding it to read/write_backend_variables, just as we add other variables for fork/exec that we want the backends to inherit. In the exec case, the executable name is actually different from the postmaster, so passing it doesn't make sense. How much do we care? AFAIK we only really care about the directory part of the path, no? There are ports that need the exact executable pathname for dynamic loading purposes, but I'd think Windows is not one of them. Agreed, but I figured we should be accurate if we can. For fork-only, our binary is postmaster, while for fork/exec, it is postgres. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Configuration parameters for plugin modules
Same patch as before but I added a small change to the gram.y enabling
SET command to use qualified names.
- thomas
Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.263
diff -u -r1.263 runtime.sgml
--- doc/src/sgml/runtime.sgml 29 Apr 2004 04:37:09 - 1.263
+++ doc/src/sgml/runtime.sgml 19 May 2004 21:01:40 -
@@ -2924,6 +2924,60 @@
/variablelist
/sect2
+ sect2 id=runtime-config-custom
+titleCustomized Options/title
+
+para
+ The following was designed to allow options not normally known to
+ productnamePostgreSQL/productname to be declared in the posgresql.conf
+ file and/or manipulated using the commandSET/command in a controlled
+ manner so that add-on modules to the postgres proper (such as lanugage
+ mappings for triggers and functions) can be configured in a unified way.
+/para
+
+variablelist
+
+ varlistentry id=guc-custom_variable_classes
xreflabel=custom_variable_classes
+ termvarnamecustom_variable_classes/varname (typestring/type)/term
+ indextermprimarycustom_variable_classes//
+ listitem
+ para
+This variable specifies one or several classes to be used for custom
+variables. A custom variable is a variable not normally known to
+the productnamePostgreSQL/productname proper but used by some add
+on module.
+ /para
+
+ para
+Aribtrary variables can be defined for each class specified here. Those
+variables will be treated as placeholders and have no meaning until the
+module that defines them is loaded. When a module for a specific class is
+loaded, it will add the proper variable definitions for the class
+associated with it, convert any placeholder values according to those
+definitions, and issue warnings for any placeholders that then remains.
+ /para
+
+ para
+Here is an example what custom variables might look like:
+
+programlisting
+custom_variable_class = 'plr,pljava'
+plr.foo = '/usr/lib/R'
+pljava.baz = 1
+plruby.var = true== this one would generate an error
+/programlisting
+ /para
+
+ para
+This option can only be set at server start or in the
+filenamepostgresql.conf/filename configuration file.
+ /para
+
+ /listitem
+ /varlistentry
+/variablelist
+ /sect2
+
sect2 id=runtime-config-developer
titleDeveloper Options/title
Index: src/backend/parser/gram.y
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/parser/gram.y,v
retrieving revision 2.454
diff -u -r2.454 gram.y
--- src/backend/parser/gram.y 10 May 2004 22:44:45 - 2.454
+++ src/backend/parser/gram.y 19 May 2004 21:01:43 -
@@ -309,7 +309,7 @@
%type strSconst comment_text
%type strUserId opt_boolean ColId_or_Sconst
%type list var_list var_list_or_default
-%type strColId ColLabel type_name param_name
+%type strColId ColLabel var_name type_name param_name
%type node var_value zone_value
%type keyword unreserved_keyword func_name_keyword
@@ -857,14 +857,14 @@
}
;
-set_rest: ColId TO var_list_or_default
+set_rest: var_name TO var_list_or_default
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-name = $1;
n-args = $3;
$$ = n;
}
- | ColId '=' var_list_or_default
+ | var_name '=' var_list_or_default
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-name = $1;
@@ -914,6 +914,19 @@
n-name = session_authorization;
n-args = NIL;
$$ = n;
+ }
+ ;
+
+var_name:
+ ColId
{ $$ = $1; }
+ | var_name '.' ColId
+ {
+ int qLen = strlen($1);
+ char* qualName = palloc(qLen + strlen($3) + 2);
+ strcpy(qualName, $1);
+ qualName[qLen] = '.';
+ strcpy(qualName + qLen + 1, $3);
+ $$ = qualName;
}
;
Index:
Re: [PATCHES] Add error-checking to timestamp_recv
Would you show an example of the invalid value this is trying to avoid? --- Stephen Frost wrote: Greetings, The attached patch adds some error-checking to the timestamp_recv function so that it's not possible to put an invalid timestamp into a timestamp column (hopefully). The check is done in basically the exact same way the out-of-bounds check in timestamp2tm is done. There's probably an easier/cleaner way but this should work or at least generate discussion and a better patch. :) Thanks, Stephen [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] pgkill for windows
I was hoping to avoid platform-specific binaries. Once pg_ctl is done in C, it can start/stop the postmaster, but not individual backends. Can we add a flag to pg_ctl so it can send arbitrary signals to processed on Win32? That would be best, I think. --- Andrew Dunstan wrote: Attached are 2 files needed to create a pgkill facility for Windows, and a complementary patch for src/bin/Makefile It is adapted from the facility on the Win32 page, but uses the builtin signal definitions rather than using its own. This facility is needed for shutting down postgres cleanly as part of 'make check', as we don't really use signals in Windows, we only emulate them using our own scheme, so any native kill program doesn't have the desired effect. cheers andrew #- # # Makefile for src/bin/pgkill # # Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group # Portions Copyright (c) 1994, Regents of the University of California # # $PostgreSQL: pgsql-server/src/bin/pgkill/Makefile,v 1.36 2004/04/26 17:40:48 momjian Exp $ # #- subdir = src/bin/pgkill top_builddir = ../../.. include $(top_builddir)/src/Makefile.global override CPPFLAGS := -DPGBINDIR=\$(bindir)\ -DPGDATADIR=\$(datadir)\ -I$(libpq_srcdir) $(CPPFLAGS) OBJS= pgkill.o all: pgkill pgkill: $(OBJS) $(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) -o [EMAIL PROTECTED](X) install: all installdirs $(INSTALL_PROGRAM) pgkill$(X) $(DESTDIR)$(bindir)/pgkill$(X) installdirs: $(mkinstalldirs) $(DESTDIR)$(bindir) uninstall: rm -f $(DESTDIR)$(bindir)/pgkill$(X) clean distclean maintainer-clean: rm -f pgkill$(X) $(OBJS) # ensure that changes in bindir etc. propagate into object file pgkill.o: pgkill.c $(top_builddir)/src/Makefile.global Index: src/bin/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/bin/Makefile,v retrieving revision 1.43 diff -c -r1.43 Makefile *** src/bin/Makefile 20 Apr 2004 00:40:06 - 1.43 --- src/bin/Makefile 10 May 2004 16:17:52 - *** *** 15,20 --- 15,24 DIRS := initdb initlocation ipcclean pg_ctl pg_dump \ psql scripts pg_config pg_controldata pg_resetxlog + ifeq ($(host_os), mingw32) + DIRS := $(DIRS) pgkill + endif + all install installdirs uninstall depend distprep: @for dir in $(DIRS); do $(MAKE) -C $$dir $@ || exit; done ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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] [HACKERS] Configuration patch
This looks very close to the method we had agreed to. I think it need a little adjustment, like removing tablespace now that the tablespaces patch is coming, but it is a great start. I could probably clean it up and apply it. Is that OK? --- [EMAIL PROTECTED] wrote: This patch incorporates a number of changes suggested by the group. The purpose of this patch is to move postgresql to a position where all configuration options are specified in one place. The postgresql.conf file could completely document a postgresql environment. It adds this functionality: The -D' option will work as it always has if it is set to a standard postgresql database cluster directory. If it is set to a postgresql.conf file, it will use that file for configuration. If it is set to a directory which is not a cluster directory, i.e. /somepath/etc it will look for pg_hba.conf, pg_ident.conf, and postgresql.conf there. For postgresql to work only with a configuration file, some options have been added: include = '/etc/postgres/debug.conf' pgdata = '/vol01/postgres' hba_conf = '/etc/postgres/pg_hba_conf' ident_conf = '/etc/postgres/pg_ident.conf' runtime_pidfile = '/var/run/postgresql.conf' tablespace = '/somevol/somepath' include allows files with configuration parameters to be included. pgdata (used to be data_dir in old patch) tells PostgreSQL where it's database cluster directory is located. hba_conf tells PostgreSQL where to find pg_hba.conf file. ident_conf tells PostgreSQL where to find pg_ident.conf. runtime_pidfile tells postgres to write it's PID to a file that would be used by external applications. It is *NOT* the pid file which postgresql uses. tablespace allows postgresql to use alternate locations without environment variables. Using SIGHUP, tablespaces are reloaded. This allows you to add tablespaces to a running PostgreSQL process. (I know this has a limited lifetime, but it may make CREATE DATABASE ... WITH LOCATION a little bit more sane in the meantime. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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] pg_ctl patch to integrate apache's rotatelogs
We documented using rotatelogs in the pg_ctl manual page, and have the main docs correct on how to use it. Hopefully that will be enough. --- Andrew Hammond wrote: [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 |logrotate rotates log files and hups the servers according to a |configuration file. rotatelogs reads the log data on stdin and reopens |a new output file once in a while. The first hunk of your patch was |wrong, the rest seemed OK. | | | OK, just to confirm, I backed out the first attached patch, but kept the | rest, which is my second attached patch. This looks correct to me. | I am still confused how these errors remained in the documentation for | so long. Probably because non-syslog logging in a production environment is a very small niche. Which might, unfortunately, be a good argument against my proposed patch. Drew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAqhIGgfzn5SevSpoRAvizAJ0fZRI5o1FuERzUen2ufWwCsz/J2ACghQ7B agaY+YaC0LIVF/jNCk+QnmA= =Rsjl -END PGP SIGNATURE- [ End of raw data] -- 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
