Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Gregory Stark wrote: "Kris Jurka" <[EMAIL PROTECTED]> writes: On Mon, 28 Jan 2008, Jeff Davis wrote: I think that pg_dump is a reasonable use case for synchoronized scans when the table has not been clustered. It could potentially make pg_dump have much less of a performance impact when run against an active system. One of the advantages I see with maintaining table dump order is that rsyncing backups to remote locations will work better. I can't see what scenario you're talking about here. pg_dump your live database, restore it elsewhere, then shut down the production database and run rsync from the live database to the restored one? Why not just run rsync for the initial transfer? take a dump (maybe in plaintext format) save it to disk and use rsync to copy it elsewhere. the more "similiar" the dumps the more efficient rsync can copy the data over. Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Unclarity of configure options
Joshua D. Drake wrote: > On Sun, 04 Nov 2007 13:24:54 -0500 > Tom Lane <[EMAIL PROTECTED]> wrote: > >> "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >>> Shouldn't --with-libxml be noted as deprecated? >> Huh? > > Because in 8.3 it is in core or am I misunderstanding the difference? you missunderstand - the XML support in 8.3 requires libxml and is only compiled in if that configure switch is selected ... Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded
Marshall, Steve wrote: > I'm glad to see the patch making its way through the process. I'm also > glad you guys do comprehensive testing before accepting it, since we are > only able to test in a more limited range of environments. > > We have applied the patch to our 8.2.4 installations and are running it > in a high transaction rate system (processing lots and lots of > continually changing weather data). Let me know if there is any > information we could provide that would be of help in making the > back-patching decision. I have re-enabled tcl builds(for -HEAD) on lionfish (mipsel) and quagga (arm) a few days ago so we should get a bit of additional coverage from boxes that definitly had problems with the tcl-threading behaviour. Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> yeah testing that patch now (seems to apply just fine on -HEAD) but it >> seems that there is something strange going on because I just got: > > ! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0 of > 8192 bytes > > Is that repeatable? What sort of filesystem are you testing on? > (soft-mounted NFS by any chance?) doesn't seem to be repeatable :-( on the postitive side - the pltcl patch does seem to fix the mentioned regression failures quagga triggered earlier this year. I did about a dozends of full buildfarm runs with that patch and about ten manual executions of the pltcl regression tests without any sign of misbehaviour so this seems like a clear candidate for at least -HEAD. Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> yeah testing that patch now (seems to apply just fine on -HEAD) but it >> seems that there is something strange going on because I just got: > > ! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0 of > 8192 bytes > > Is that repeatable? What sort of filesystem are you testing on? that box is slow - still testing ... > (soft-mounted NFS by any chance?) no - local SATA disk with ext3 (no OS related errors and SMART is clean too) Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> hmm i wonder if that could be related to: >> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00377.php > > I had forgotten that thread, but it sure does look related doesn't it? > Do you want to try Steve's proposed patch and see if it fixes it? yeah testing that patch now (seems to apply just fine on -HEAD) but it seems that there is something strange going on because I just got: http://www.kaltenbrunner.cc/files/regression.diffs on the first manual buildfarm run on quagga... Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded
Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: >> "Bruce Momjian" <[EMAIL PROTECTED]> writes: There is a problem in PL/TCL that can cause the postgres backend to become multithreaded. Postgres is not designed to be multithreaded, so this causes downstream errors in signal handling. > >> Um, this is a bug fix. Unless you had some problem with it? > > I haven't reviewed that patch yet, but I concur we should consider it > for 8.3. hmm i wonder if that could be related to: http://archives.postgresql.org/pgsql-hackers/2007-01/msg00377.php Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] tab complete changes
the attached patch makes teh following changes to the psql tab-complete
support
* adds a few missing words to some commands (like adding GIN as a valid
index type or OWNED BY for ALTER SEQUENCE,...)
* support for ALTER TABLE foo ENABLE/DISABLE REPLICA TRIGGER/RULE
* autocomplete CREATE DATABASE foo TEMPLATE (mostly done to prevent
conflicts with the TEMPLATE keyword for text search)
* support for ALTER/CREATE/DROP TEXT SEARCH as well as COMMENT ON TEXT
SEARCH and the corresponding psql backslash commands.
This proved a little more difficult than expected due to the fact that
words_after_create[] is used for two purposes - one is to provide a list
of words that follow immediatly after CREATE (or DROP) and the other
purpose is to use it for autocompleting anywhere in the statement if the
word in that struct is found with a query.
Since TEXT SEARCH CONFIGURATION|DICTIONARY|TEMPLATE|PARSER results in 3
words instead of one (as all the other words in that list are) I added a
flag to the struct to tell create_command_generator() to skip that entry
for autocompleting immediatly after CREATE which feels like a dirty
hack (but that holds true for a lot of code in tab-complete.c).
Stefan
Index: src/bin/psql/tab-complete.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/tab-complete.c,v
retrieving revision 1.166
diff -c -r1.166 tab-complete.c
*** src/bin/psql/tab-complete.c 3 Jul 2007 01:30:37 - 1.166
--- src/bin/psql/tab-complete.c 25 Aug 2007 11:17:23 -
***
*** 328,333
--- 328,337
" AND pg_catalog.quote_ident(relname)='%s' "\
" AND pg_catalog.pg_table_is_visible(c.oid)"
+ #define Query_for_list_of_template_databases \
+ "SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database "\
+ " WHERE substring(pg_catalog.quote_ident(datname),1,%d)='%s' and
datistemplate IS TRUE"
+
#define Query_for_list_of_databases \
"SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database "\
" WHERE substring(pg_catalog.quote_ident(datname),1,%d)='%s'"
***
*** 419,424
--- 423,444
" (SELECT tgrelid FROM pg_catalog.pg_trigger "\
" WHERE pg_catalog.quote_ident(tgname)='%s')"
+ #define Query_for_list_of_ts_configurations \
+ "SELECT pg_catalog.quote_ident(cfgname) FROM pg_catalog.pg_ts_config "\
+ " WHERE substring(pg_catalog.quote_ident(cfgname),1,%d)='%s'"
+
+ #define Query_for_list_of_ts_dictionaries \
+ "SELECT pg_catalog.quote_ident(dictname) FROM pg_catalog.pg_ts_dict "\
+ " WHERE substring(pg_catalog.quote_ident(dictname),1,%d)='%s'"
+
+ #define Query_for_list_of_ts_parsers \
+ "SELECT pg_catalog.quote_ident(prsname) FROM pg_catalog.pg_ts_parser "\
+ " WHERE substring(pg_catalog.quote_ident(prsname),1,%d)='%s'"
+
+ #define Query_for_list_of_ts_templates \
+ "SELECT pg_catalog.quote_ident(tmplname) FROM pg_catalog.pg_ts_template "\
+ " WHERE substring(pg_catalog.quote_ident(tmplname),1,%d)='%s'"
+
/*
* This is a list of all "things" in Pgsql, which can show up after CREATE or
* DROP; and there is also a query to get a list of them.
***
*** 429,434
--- 449,455
const char *name;
const char *query; /* simple query, or NULL */
const SchemaQuery *squery; /* schema query, or NULL */
+ const bool noshow; /* NULL or true if this word should not show up
after CREATE or DROP */
} pgsql_thing_t;
static const pgsql_thing_t words_after_create[] = {
***
*** 440,447
--- 461,470
* CREATE CONSTRAINT TRIGGER is not supported here because it is
designed
* to be used only by pg_dump.
*/
+ {"CONFIGURATION", Query_for_list_of_ts_configurations, NULL, true},
{"CONVERSION", "SELECT pg_catalog.quote_ident(conname) FROM
pg_catalog.pg_conversion WHERE
substring(pg_catalog.quote_ident(conname),1,%d)='%s'"},
{"DATABASE", Query_for_list_of_databases},
+ {"DICTIONARY", Query_for_list_of_ts_dictionaries, NULL, true},
{"DOMAIN", NULL, &Query_for_list_of_domains},
{"FUNCTION", NULL, &Query_for_list_of_functions},
{"GROUP", Query_for_list_of_roles},
***
*** 449,454
--- 472,478
{"INDEX", NULL, &Query_for_list_of_indexes},
{"OPERATOR", NULL, NULL}, /* Querying for this is probably not
such a
* good idea. */
+ {"PARSER", Query_for_list_of_ts_parsers, NULL, true},
{"ROLE", Query_for_list_of_roles},
{"RULE", "SELECT pg_catalog.quote_ident(rulename) FROM
pg_catalog.pg_rules WHERE
substring(pg_catalog.quote_ident(rulename),1,%d)='%s'"},
{"SCHEMA", Query_for_list_of_schemas},
***
*** 456,467
{"TABLE", NULL, &Query_for_list_of_tables},
{"TABLESPACE", Query_for_list_of_tablespaces},
{"TEMP", NULL, NULL},
[PATCHES] bogus unixware compiler warnings
I'm slowly working on submitting patches to reduce the amount of (bogus) compiler warnings generated by various buildfarm members. Warthog(the unixware box) generates some 1140 lines of: UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled which seems to be a result of having both -g and -O in CFLAGS - Olivier was so kind to test the attached patch which get's rid of all those bogus warnings (and seems to be in line with what we are doing on other platforms like solaris). Stefan Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql/src/template/unixware,v retrieving revision 1.41 diff -c -r1.41 unixware *** src/template/unixware 14 Dec 2006 21:49:54 - 1.41 --- src/template/unixware 15 Jul 2007 16:54:43 - *** *** 11,21 f(0, 0); } __EOF__ ! if $CC -c -O -Kinline conftest.c >conftest.err 2>&1; then ! CFLAGS="-O -Kinline" else ! CFLAGS="-O -Kinline,no_host" fi rm -f conftest.* --- 11,23 f(0, 0); } __EOF__ ! if test "$enable_debug" != yes; then ! CFLAGS="-O" ! fi if $CC -c -O -Kinline conftest.c >conftest.err 2>&1; then ! CFLAGS="$CFLAGS -Kinline" else ! CFLAGS="$CFLAGS -Kinline,no_host" fi rm -f conftest.* ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] HOT latest patch - version 8
Heikki Linnakangas wrote: > Stefan Kaltenbrunner wrote: >> tried to test a bit on my Solaris 10 install(sun studio , 64bit build) >> but I'm hitting the following while trying to initdb a new cluster: > > I can't reproduce this error, but I found a bug that's likely causing > it. The patch uses InvalidOffsetNumber in lp_off to mark so called > "redirect dead" line pointers, but that special case is not checked in > PageGetRedirectingOffset-function, writing to a caller-supplied array > with -1 index instead, globbering over whatever is there. Actually > storing InvalidOffsetNumber in lp_off is a bit bogus in the first place > since lp_off is unsigned, and InvalidOffsetNumber is -1, so I fixed that > as well. this seems to fix the problem for me - a least I can now successfully initdb a new cluster with the HOT patch applied. Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] HOT latest patch - version 8
Pavan Deolasee wrote: > > Please see updated version of the patch. This includes further code > refactoring and bug fixes. > > heapam code is now refactored and I have also added several comments > in that code as well as vacuum and create index related code. > > In the previous version, we were not collecting aborted heap-only > tuples since they are not part of any chain. This version deals with > such tuples. > > There is also some cleanup in the VACUUM FULL area. Especially > we have dealt with the redirected line pointers by pointing them to > the first non-dead tuple in the chain. Since we hold exclusive lock > on the relation, we can easily do that. > > Anyways, we still need a comprehensive writeup, but if someone > wants to test things further, this patch should be used. tried to test a bit on my Solaris 10 install(sun studio , 64bit build) but I'm hitting the following while trying to initdb a new cluster: program terminated by signal SEGV (no mapping at the fault address) Current function is PageGetRedirectingOffset 1186 offsets[ItemIdGetRedirect(lp) - 1] = offnum; (dbx) where =>[1] PageGetRedirectingOffset(page = 0xfd7ffdf2bea0 "", offsets = 0xfd7fffdfd2fc, size = 582), line 1186 in "bufpage.c" [2] lazy_scan_heap(onerel = 0xc7fcd8, vacrelstats = 0xcb9940, Irel = 0xcd0008, nindexes = 2), line 434 in "vacuumlazy.c" [3] lazy_vacuum_rel(onerel = 0xc7fcd8, vacstmt = 0xc34e70, bstrategy = 0xcb76d8), line 187 in "vacuumlazy.c" [4] vacuum_rel(relid = 2608U, vacstmt = 0xc34e70, expected_relkind = 'r'), line 1109 in "vacuum.c" [5] vacuum(vacstmt = 0xc34e70, relids = (nil), bstrategy = 0xcb76d8, isTopLevel = '\001'), line 424 in "vacuum.c" [6] ProcessUtility(parsetree = 0xc34e70, queryString = 0xbcd978 "VACUUM pg_depend;\n", params = (nil), isTopLevel = '\001', dest = 0xb0f440, completionTag = 0xfd7fffdff5d0 ""), line 997 in "utility.c" [7] PortalRunUtility(portal = 0xcc5328, utilityStmt = 0xc34e70, isTopLevel = '\001', dest = 0xb0f440, completionTag = 0xfd7fffdff5d0 ""), line 1179 in "pquery.c" [8] PortalRunMulti(portal = 0xcc5328, isTopLevel = '\001', dest = 0xb0f440, altdest = 0xb0f440, completionTag = 0xfd7fffdff5d0 ""), line 1267 in "pquery.c" [9] PortalRun(portal = 0xcc5328, count = 9223372036854775807, isTopLevel = '\001', dest = 0xb0f440, altdest = 0xb0f440, completionTag = 0xfd7fffdff5d0 ""), line 814 in "pquery.c" [10] exec_simple_query(query_string = 0xc34c08 "VACUUM pg_depend;\n"), line 967 in "postgres.c" [11] PostgresMain(argc = 8, argv = 0xb94c68, username = 0xb8dd10 "pgbuild"), line 3527 in "postgres.c" [12] main(argc = 9, argv = 0xb94c60), line 186 in "main.c" Stefan ---(end of broadcast)--- TIP 1: 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
[PATCHES] GSSAPI support on solaris
the attached patch adds -lgss to the autoconf tests and enables --with-gssapi builds on solaris 10 (and probably others). Stefan Index: configure === RCS file: /projects/cvsroot/pgsql/configure,v retrieving revision 1.553 diff -c -r1.553 configure *** configure 12 Jul 2007 14:36:52 - 1.553 --- configure 14 Jul 2007 07:53:56 - *** *** 6824,6830 rm -f conftest.err conftest.$ac_objext \ conftest$ac_exeext conftest.$ac_ext if test "$ac_cv_search_gss_init_sec_context" = no; then ! for ac_lib in gssapi_krb5 'gssapi -lkrb5 -lcrypto'; do LIBS="-l$ac_lib $ac_func_search_save_LIBS" cat >conftest.$ac_ext <<_ACEOF /* confdefs.h. */ --- 6824,6830 rm -f conftest.err conftest.$ac_objext \ conftest$ac_exeext conftest.$ac_ext if test "$ac_cv_search_gss_init_sec_context" = no; then ! for ac_lib in gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'; do LIBS="-l$ac_lib $ac_func_search_save_LIBS" cat >conftest.$ac_ext <<_ACEOF /* confdefs.h. */ Index: configure.in === RCS file: /projects/cvsroot/pgsql/configure.in,v retrieving revision 1.520 diff -c -r1.520 configure.in *** configure.in12 Jul 2007 14:36:52 - 1.520 --- configure.in14 Jul 2007 07:53:57 - *** *** 767,773 if test "$with_gssapi" = yes ; then if test "$PORTNAME" != "win32"; then ! AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 'gssapi -lkrb5 -lcrypto'], [], [AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])]) else LIBS="$LIBS -lgssapi32" --- 767,773 if test "$with_gssapi" = yes ; then if test "$PORTNAME" != "win32"; then ! AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [], [AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])]) else LIBS="$LIBS -lgssapi32" ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] GSSAPI support on OpenBSD
The just commited GSSAPI patch is unable to find the required libraries and includes on OpenBSD (which are in /usr/include/kerberosV/) - the attached patch allows building with gssapi support on OpenBSD 4.0/amd64 (and still seems to build fine on Debian Etch/x86_64). Note that the patch does not include the derived filess o one needs to make sure they are getting regenerated before commit. Stefan Index: configure.in === RCS file: /projects/cvsroot/pgsql/configure.in,v retrieving revision 1.518 diff -c -r1.518 configure.in *** configure.in10 Jul 2007 16:41:01 - 1.518 --- configure.in11 Jul 2007 12:58:09 - *** *** 767,774 if test "$with_gssapi" = yes ; then if test "$PORTNAME" != "win32"; then ! AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5], [], ! [AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])]) else LIBS="$LIBS -lgssapi32" fi --- 767,774 if test "$with_gssapi" = yes ; then if test "$PORTNAME" != "win32"; then ! AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 'gssapi -lkrb5 -lcrypto'], [], ! [AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])]) else LIBS="$LIBS -lgssapi32" fi *** *** 870,876 fi if test "$with_gssapi" = yes ; then ! AC_CHECK_HEADER(gssapi/gssapi.h, [], [AC_MSG_ERROR([header file is required for GSSAPI])]) fi if test "$with_krb5" = yes ; then --- 870,877 fi if test "$with_gssapi" = yes ; then ! AC_CHECK_HEADERS(gssapi/gssapi.h, [], ! [AC_CHECK_HEADERS(gssapi.h, [], [AC_MSG_ERROR([gssapi.h header file is required for GSSAPI])])]) fi if test "$with_krb5" = yes ; then Index: src/backend/libpq/auth.c === RCS file: /projects/cvsroot/pgsql/src/backend/libpq/auth.c,v retrieving revision 1.150 diff -c -r1.150 auth.c *** src/backend/libpq/auth.c11 Jul 2007 08:27:33 - 1.150 --- src/backend/libpq/auth.c11 Jul 2007 12:58:09 - *** *** 302,308 --- 302,312 * */ + #if defined(HAVE_GSSAPI_H) + #include + #else #include + #endif #ifdef WIN32 /* Index: src/include/libpq/libpq-be.h === RCS file: /projects/cvsroot/pgsql/src/include/libpq/libpq-be.h,v retrieving revision 1.59 diff -c -r1.59 libpq-be.h *** src/include/libpq/libpq-be.h10 Jul 2007 13:14:21 - 1.59 --- src/include/libpq/libpq-be.h11 Jul 2007 12:58:10 - *** *** 30,37 --- 30,41 #endif #ifdef ENABLE_GSS + #if defined(HAVE_GSSAPI_H) + #include + #else #include #endif + #endif #include "libpq/hba.h" #include "libpq/pqcomm.h" Index: src/interfaces/libpq/fe-auth.c === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-auth.c,v retrieving revision 1.124 diff -c -r1.124 fe-auth.c *** src/interfaces/libpq/fe-auth.c 10 Jul 2007 13:14:21 - 1.124 --- src/interfaces/libpq/fe-auth.c 11 Jul 2007 12:58:10 - *** *** 317,323 --- 317,327 /* * GSSAPI authentication system. */ + #if defined(HAVE_GSSAPI_H) + #include + #else #include + #endif #ifdef WIN32 /* Index: src/interfaces/libpq/libpq-int.h === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/libpq-int.h,v retrieving revision 1.122 diff -c -r1.122 libpq-int.h *** src/interfaces/libpq/libpq-int.h10 Jul 2007 13:14:22 - 1.122 --- src/interfaces/libpq/libpq-int.h11 Jul 2007 12:58:10 - *** *** 45,52 --- 45,56 #include "pqexpbuffer.h" #ifdef ENABLE_GSS + #if defined(HAVE_GSSAPI_H) + #include + #else #include #endif + #endif #ifdef USE_SSL #include ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] SPI-header-files safe for C++-compiler
Tom Lane wrote: > "Jacob Rief" <[EMAIL PROTECTED]> writes: >> Just for curiosity, I would like to ask something. >> libpqxx is based on libpq, and thus includes headers-files from libpq. >> These header-files are C++-safe, otherwise libpqxx would'nt compile. > > Well, if they are, it's only by chance, because there isn't much of > anything verifying that they are safe :-(. wild idea - we could add a bit of configure magic and a special makefile target and add a buildfarm stage for that and have it automatically check for these things ? Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [DOCS] rename of a view
Neil Conway wrote: > On Mon, 2007-02-07 at 23:13 -0400, Tom Lane wrote: >> Er, was this on the agenda for 8.3? > > Well, it seemed fairly harmless to me (no behavioral changes and very > little new code, just syntax), so I didn't see a compelling reason to > delay applying it for a few months. But I can revert it if you'd prefer. hmm so now we have ALTER VIEW/SEQUENCE commands that can do a bit but not all of what ALTER TABLE can do (renaming columns of a VIEW or changing the owner for example). I agree in principle that having those functionality in ALTER VIEW/SEQUENCE is a good idea but only bringing in a bit of the required functionality which still does not solve the "uhm why do I need ALTER TABLE to manipulate a VIEW" months after the feature freeze sounds a bit wrong to me :-( Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] build/install xml2 when configured with libxml
Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Peter Eisentraut wrote: >>> But the policy is that the presence of features in the final build >>> should not depend on the incidental presence of features in the build >>> environment. Either you select a feature, then it's built, or you >>> don't, then it's not. So the only options we really have are adding >>> another switch for libxslt, or including it with libxml. I'm not sure >>> which is better. > >> Then let's add a switch for libxslt. > > +1 --- the fact that so many buildfarm members only have one of the two > libraries is pretty suggestive that that's common. We shouldn't require > both libraries to build the core xml features, if only because > contrib/xml2 is expected to go away eventually, no? well from a buildfarm maintainer perspective - I only have (or had on some boxes) only libxml(or rather libxm-dev) installed because that's what was required when we got the initial XML support. Most of those boxes would have neither of those two - it's the buildfarm itself that resulted in that library getting installed (and only that one because it was sufficient at the time). Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES]
Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> ... In regards to your idea of a filter, there is no reason why >> we couldn't install a filter that checks for signatures with specific >> legal words and strips said signature automatically, responding to the >> sender that we did so. > > The problem is that if $SENDER's corporate lawyers actually think that > it means something to put a restriction-of-rights notice on a message > sent to a public mailing list, then they might think that posting the > message with the notice stripped represents a violation of their barren > intellectual property :-(. What I'd like us to do is bounce it back. > A slightly cleaner version of the notice might be "If you wish to post > this message on our worldwide mailing lists, and thereby make unrepaid > use of our redistribution and archiving resources, then you may not > assert the right to restrict redistribution of your message." > > Not that I think that anyone owning both a law degree and a computer > in 2007 should legitimately be able to plead innocence here. FAST > Australia's lawyers are making themselves look like idiots, and the > same for every other company tacking on such notices. I think the > real bottom line here is "we don't accept patches from idiots". I think "we don't accept patches from idiots" is a bit harsh. There are quite a few skilled developers out there working for large companies that are not doing most of their day-to-day business with OSS software(and therefor know how to interact with the community). Working in such a large environment requires one to use the tools and infrastructure provided by the company - while I fully agree that email sigs are one of the more stupid things it is often something the individual person might not even know about (gets added at the gateway) or can do much about it. Stefan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] guid/uuid datatype
Neil Conway wrote: On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I'd be curious to know the degree to which the proposed patch is consistent with RFC 4122, which AFAIK is the most recent relevant standard. With regard to functions for generating UUIDs, I think we should at least include the methods specified by RFC 4122 that can be implemented without too many unportable assumptions. I believe that means MD5 & SHA1 hashing of an arbitrary identifier, and UUIDs generated via a PSRNG. I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] guid/uuid datatype
Alvaro Herrera wrote: > Magnus Hagander wrote: >> Gevik Babakhani wrote: I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? >>> This is also a point I remember from the last discussions. To not to >>> include the generator in the core. The generation of the uuid is then >>> going to be on the client side. >>> >>> The uuid type is very useful, especially when migrating from other >>> systems to pg (ms->pg or syb->pg). >> But does it really help if you don't have the generator? > > We could have all the type code in core, and the generator in contrib or > pgfoundry. That way the user can choose the most appropriate generator, > even if it's platform-specific. Or he can choose to use a client-side > generator. that seems like a good compromise - have the type in core and generators in contrib/pgfoundry. In one or two releases we might see some feedback on the portability and how people use those and could decide on leaving it that way or move the generators into core as well. Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [PATCHES] fix build on Solaris 10/x86_64 in 64bit mode with Sun
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> on an Intel based Solaris 10U2 box using Sun Studio 11 with >> -xarch=generic64 we get a compile time failure in contrib/pgcrypto >> because BYTE_ORDER is not defined. > > After further thought I changed this to handle either __amd64 or > __x86_64 (or both). Applied. I think it defines both at all times - if we want fewer rules in there we could switch to just testing __x86 für both 64bit and 32bit but I guess it's fine as it stands now. Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] [PATCHES] fix build on Solaris 10/x86_64 in 64bit mode with Sun
Stefan Kaltenbrunner wrote: on an Intel based Solaris 10U2 box using Sun Studio 11 with -xarch=generic64 we get a compile time failure in contrib/pgcrypto because BYTE_ORDER is not defined. in src/include/port/solaris.h we define it to little endian only for __i386 - however in 64bit mode the compiler only defines __amd64 causing YTE_ORDER to be undefined. The other option would be to use __x86 which is defined on all intel architectures. attached is a quick hack to allow pgcrypto to compile on that platform. buildfarm report for that issue: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=clownfish&dt=2007-01-10%2014:18:23 Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] fix build on Solaris 10/x86_64 in 64bit mode with Sun Studio 11
on an Intel based Solaris 10U2 box using Sun Studio 11 with -xarch=generic64 we get a compile time failure in contrib/pgcrypto because BYTE_ORDER is not defined. in src/include/port/solaris.h we define it to little endian only for __i386 - however in 64bit mode the compiler only defines __amd64 causing YTE_ORDER to be undefined. The other option would be to use __x86 which is defined on all intel architectures. attached is a quick hack to allow pgcrypto to compile on that platform. Stefan --- /export/home/pgbuild/pgbuildfarm/HEAD/pgsql/src/include/port/solaris.h Thu Oct 5 00:49:44 2006 +++ src/include/port/solaris.h Sun Jan 7 09:24:51 2007 @@ -5,6 +5,10 @@ * symbols are defined on both GCC and Solaris CC, although GCC * doesn't document them. The __xxx__ symbols are only on GCC. */ +#if defined(__amd64) && !defined(__amd64__) +#define __amd64__ +#endif + #if defined(__i386) && !defined(__i386__) #define __i386__ #endif @@ -34,6 +38,9 @@ #ifdef __i386__ #define BYTE_ORDER LITTLE_ENDIAN #endif +#ifdef __amd64__ +#define BYTE_ORDER LITTLE_ENDIAN +#endif #endif /* ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Recent SIGSEGV failures in buildfarm HEAD
Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> ... And then we'd need to change the regression makefile to use >> the option, based on an environment variable a bit like MAX_CONNEXCTIONS >> maybe. > > Why wouldn't we just use it always? If a regression test dumps core, > that's going to deserve investigation. enabling it always for the regression tests probably makes sense - but there is also the possibility that such a core can get very large and potentially run the partitition the regression test runs on out of space. Stefan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] COPY view
Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian <[EMAIL PROTECTED]> writes: >>> OK, based on this feedback, I am adding COPY VIEW to the patches queue. >> I think we have other things that demand our attention more than a >> half-baked feature. > > Well, the patch was submitted in time, and it is a desired feature. If > we want to hold it for 8.3 due to lack of time, we can, but I don't > think we can decide now that it must wait. well I thought the agreed approach to that was allowing COPY from arbitrary expressions without the need to go through the extra CREATE VIEW step? Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] -HEAD pg_dumpall broken against older backends
Peter Eisentraut wrote: > Stefan Kaltenbrunner wrote: > >>looks like somebody forgot to test some changes to the pg_dumpall >>code in Revision 1.70 against <8.1 installations - resulting in the >>following syntax error: > > > Dump output is never expected to be backward compatible. yeah - but if you take a look at the code/patch you will see that the problem in this case is that pg_dumpall generates invalid SQL if it is operating against an older backend which is an obvious typo/thinko in this case. It has nothing to do with generating backwards compatible dumps - and using the pg_dumpall from the (newer) target version for upgrades has been recommended for a while (or rather is documented to work in the manual) I think. Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] -HEAD pg_dumpall broken against older backends
Hi! looks like somebody forgot to test some changes to the pg_dumpall code in Revision 1.70 against <8.1 installations - resulting in the following syntax error: -- -- PostgreSQL database cluster dump -- \connect postgres pg_dumpall: query failed: ERROR: syntax error at or near "null" LINE 1: ... passwd as rolpassword, valuntil as rolvaliduntil null as ro... ^ pg_dumpall: query was: SELECT usename as rolname, usesuper as rolsuper, true as rolinherit, usesuper as rolcreaterole, usecreatedb as rolcreatedb, usecatupd as rolcatupdate, true as rolcanlogin, -1 as rolconnlimit, passwd as rolpassword, valuntil as rolvaliduntil null as rolcomment FROM pg_shadow UNION ALL SELECT groname as rolname, false as rolsuper, true as rolinherit, false as rolcreaterole, false as rolcreatedb, false as rolcatupdate, false as rolcanlogin, -1 as rolconnlimit, null::text as rolpassword, null::abstime as rolvaliduntil null FROM pg_group proposed patch to fix problem is attached. Stefan Index: src/bin/pg_dump/pg_dumpall.c === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dumpall.c,v retrieving revision 1.72 diff -u -r1.72 pg_dumpall.c --- src/bin/pg_dump/pg_dumpall.c5 Mar 2006 15:58:51 - 1.72 +++ src/bin/pg_dump/pg_dumpall.c29 Mar 2006 13:29:01 - @@ -444,7 +444,7 @@ "true as rolcanlogin, " "-1 as rolconnlimit, " "passwd as rolpassword, " - "valuntil as rolvaliduntil " + "valuntil as rolvaliduntil, " "null as rolcomment " "FROM pg_shadow " "UNION ALL " @@ -457,8 +457,8 @@ "false as rolcanlogin, " "-1 as rolconnlimit, " "null::text as rolpassword, " - "null::abstime as rolvaliduntil " - "null " + "null::abstime as rolvaliduntil, " + "null as rolcomment " "FROM pg_group"); res = executeQuery(conn, buf->data); ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] AIX FAQ addition
Chris Browne wrote: > We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3 > to fail to successfully build the release candidates. > > However, a patch has emerged (thanks, Seneca!) that does allow it to > work, and which I'd expect to be portable (better still!). > > We are still actively pursuing why it breaks, but supposing that still > remains outstanding, at least the following would allow AIX users to > better survive a build... I can confirm that with that patch applied 8.1RC1 builds and passes a complete run of the buildfarm-script(including plpython and with a simple makefile-fix plperl) compiled with gcc 4.0.2 and xlc. So I think we should definitly add this to the FAQ at least. Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] psql tab-complete and backslash patch
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>attached is a patch against psql that makes psql's tabcomplete code >>ROLES aware, adds SET SCHEMA and basic CREATE DATABASE/TRIGGER support >>as well as some other minor things. > > > Applied with some changes. I didn't see the point of making \du > backwards compatible to older versions; we've never worried about that > before in psql's \d commands. Also I thought the "Attributes" approach > of the old \du code was well past its usefulness, so I just changed it > to separate columns. thanks for applying! While I know that we have never guaranteed backwards-compatibility for psql's backslash commands (or for tab-complete either) I modeled this after the \db-tablespace code. Removing it altogether is fine too :-) Any particular reason why you dropped the SET SCHEMA part of my patch ? Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] psql tab-complete and backslash patch
Hi!
attached is a patch against psql that makes psql's tabcomplete code
ROLES aware, adds SET SCHEMA and basic CREATE DATABASE/TRIGGER support
as well as some other minor things.
In addition to this I modified \du to display a list of roles with some
additional information(createrole,connection limit) on 8.1 with a
fallback to the original output on older backends.
There are a few problems still left - in particular the the tab-complete
code is a little inconsistent wrt completing USER/ROLE/GROUP/OWNER TO
with roles or users/groups (from the pg_user/pg_group views)
comments(especially about the \du change)?
regards
Stefan Kaltenbrunner
Changes in Detail:
*) SET SCHEMA for ALTER AGGREGATE,FUNCTION.DOMAIN,SEQUENCE,TABLE,TYPE
*) add CONNECTION LIMIT to ALTER DATABASE
*) add support for ALTER ROLE
*) make ALTER USER aware about ROLES
*) COMMENT ON LARGE OBJECT
*) add support for CREATE DATABASE
*) add support for CREATE TRIGGER
*) add support for CREATE USER,ROLE,GROUP
*) complete SET ROLE with a list of roles
*) complete SET SCHEMA with a list of schemas
*) complete SET SESSION AUTHORIZATION with list of roles
*) fixes a small typo in a comment (ANALZYE -> ANALYZE)
*) modify \du to display createrole and the connection limit
Index: src/bin/psql/command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.151
diff -u -r1.151 command.c
--- src/bin/psql/command.c 25 Jul 2005 17:17:41 - 1.151
+++ src/bin/psql/command.c 13 Aug 2005 10:47:36 -
@@ -363,7 +363,7 @@
success = listTables(&cmd[1], pattern,
show_verbose);
break;
case 'u':
- success = describeUsers(pattern);
+ success = describeRoles(pattern);
break;
default:
Index: src/bin/psql/describe.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.122
diff -u -r1.122 describe.c
--- src/bin/psql/describe.c 18 Jul 2005 19:09:09 - 1.122
+++ src/bin/psql/describe.c 13 Aug 2005 10:47:38 -
@@ -1379,23 +1379,24 @@
/*
* \du
*
- * Describes users. Any schema portion of the pattern is ignored.
+ * Describes Roles. Any schema portion of the pattern is ignored.
*/
bool
-describeUsers(const char *pattern)
+describeRoles(const char *pattern)
{
PQExpBufferData buf;
PGresult *res;
printQueryOpt myopt = pset.popt;
initPQExpBuffer(&buf);
-
+ if (pset.sversion < 80100)
+{
printfPQExpBuffer(&buf,
"SELECT u.usename AS \"%s\",\n"
" u.usesysid AS \"%s\",\n"
" CASE WHEN u.usesuper AND
u.usecreatedb THEN CAST('%s' AS pg_catalog.text)\n"
- " WHEN u.usesuper THEN CAST('%s' AS
pg_catalog.text)\n"
-" WHEN u.usecreatedb THEN CAST('%s' AS
pg_catalog.text)\n"
+ " WHEN u.usesuper THEN
CAST('%s' AS pg_catalog.text)\n"
+ " WHEN u.usecreatedb THEN
CAST('%s' AS pg_catalog.text)\n"
" ELSE CAST('' AS
pg_catalog.text)\n"
" END AS \"%s\",\n"
" ARRAY(SELECT g.groname FROM
pg_catalog.pg_group g WHERE u.usesysid = ANY(g.grolist)) as \"%s\"\n"
@@ -1408,6 +1409,37 @@
processNamePattern(&buf, pattern, false, false,
NULL, "u.usename", NULL, NULL);
+ myopt.title = _("List of users");
+} else {
+ printfPQExpBuffer(&buf,
+ "SELECT r.rolname AS \"%s\",\n"
+ " CASE WHEN r.rolsuper AND
r.rolcreaterole AND r.rolcreatedb THEN CAST('%s' AS pg_catalog.text)\n"
+ " WHEN r.rolsuper AND
r.rolcreaterole THEN CAST('%s' AS pg_catalog.text)\n"
+ " WHEN r.rolsuper AND r.rolcreatedb
THEN CAST('%s' AS pg_catalog.text)\n"
+ " WHEN r.rolsuper THEN CAST('%s' AS
pg_catalog.text)\n"
+ " WHEN r.rolcreaterole AND
r.rolcreatedb THEN CAST(&#
Re: [PATCHES] Post-mortem: final 2PC patch
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>the machine had some issues a week ago or so - but it looks like the >>problem occured first here: > > > Hmm, what kind of issues, and are you sure they are fixed? admin error :-). I had a second postgresql instance running causing the buildfarm runs to report a failure because of shared memory-limits. Had nothing to do with hardware problems though ... > > The stack trace looks to me like it is trying to apply the PGTZ setting > that's coming in from the client during startup. Now I could believe a > platform-specific breakage there from Magnus' recent hacking, but the > problem is that *every* backend launched during the regression tests > is going to be doing this, and doing it in the same way with the same > value. It's pretty tough to see why some backends would fail at this > spot and some not ... unless what it is is an intermittent hardware > problem. Is there a version of memtest86 that works on your machine? memtest86 works on x86 CPU's only afaik - no ? anyway - here is the promised backtrace: #0 0x4489fba4 in memcpy () from /usr/lib/libc.so.34.2 #1 0x00326f9c in hash_search (hashp=0xa6e030, keyPtr=0xa5ff90, action=HASH_ENTER, foundPtr=0x0) at dynahash.c:653 #2 0x003434f0 in pg_tzset (name=0xa5ff90 "PST8PDT") at pgtz.c:1039 #3 0x001fbcf0 in assign_timezone (value=0xa5ff90 "PST8PDT", doit=1 '\001', source=PGC_S_CLIENT) at variable.c:351 #4 0x00330f28 in set_config_option (name=0xa52830 "timezone", value=0xa52870 "PST8PDT", context=10645504, source=PGC_S_CLIENT, isLocal=0 '\0', changeVal=1 '\001') at guc.c:3748 #5 0x0029b5f0 in PostgresMain (argc=4, argv=0xa52928, username=0xa52740 "mastermind") at postgres.c:2759 #6 0x0026b180 in BackendRun (port=0xa77800) at postmaster.c:2800 #7 0x0026aa30 in BackendStartup (port=0xa77800) at postmaster.c:2440 #8 0x002685fc in ServerLoop () at postmaster.c:1221 #9 0x00267bc8 in PostmasterMain (argc=0, argv=0x57d8) at postmaster.c:930 #10 0x00220cc8 in main (argc=6, argv=0x57d8) at main.c:268 Stefan ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Post-mortem: final 2PC patch
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>>Can you get a stack trace from the core dump? > > >>(gdb) bt >>#0 0x50377ba4 in memcpy () from /usr/lib/libc.so.34.2 >>#1 0x00326efc in hash_search () >>#2 0x00343430 in pg_tzset () >>#3 0x001fbcf0 in assign_timezone () >>#4 0x00330e88 in set_config_option () >>#5 0x0029b5b0 in PostgresMain () >>#6 0x0026b140 in BackendRun () >>#7 0x0026a9f0 in BackendStartup () >>#8 0x002685bc in ServerLoop () >>#9 0x00267b88 in PostmasterMain () >>#10 0x00220cc8 in main () > > >>hmm - maybe one of the timezone patches ? > > > Looks suspicious, doesn't it. How long since you last tested on that > machine? *argl* - it's not 2PC ... the machine had some issues a week ago or so - but it looks like the problem occured first here: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2005-06-15%2023:50:04 and in that changeset we have some timezone-patches ... Stefan ---(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] Post-mortem: final 2PC patch
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>FYI: this commit seems to cause problems/crashes during make check on my >>OpenBSD/Sparc64 buildfarmclient: > > >>http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2005-06-17%2023:50:04 > > >>I just checked manually with a fresh checkout - and I got similiar failures. > > > Can you get a stack trace from the core dump? (gdb) bt #0 0x50377ba4 in memcpy () from /usr/lib/libc.so.34.2 #1 0x00326efc in hash_search () #2 0x00343430 in pg_tzset () #3 0x001fbcf0 in assign_timezone () #4 0x00330e88 in set_config_option () #5 0x0029b5b0 in PostgresMain () #6 0x0026b140 in BackendRun () #7 0x0026a9f0 in BackendStartup () #8 0x002685bc in ServerLoop () #9 0x00267b88 in PostmasterMain () #10 0x00220cc8 in main () rebuilding with --enable-debug right now ... > > As best I can tell from the buildfarm report, one of the regression > tests is causing a sig11 --- but it's *not* the prepared_xacts test, > so I'm not sure the failure is related to this patch. hmm - maybe one of the timezone patches ? Stefan ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Post-mortem: final 2PC patch
Tom Lane wrote: > I've attached the 2PC patch as applied in case you want to have a look. > I did some fairly significant hacking on it, and I thought it'd be a > good idea to enumerate some of the changes: FYI: this commit seems to cause problems/crashes during make check on my OpenBSD/Sparc64 buildfarmclient: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2005-06-17%2023:50:04 I just checked manually with a fresh checkout - and I got similiar failures. Stefan ---(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] psql tab-complete patch #3
Bruce Momjian wrote:
Great, patch applied. I merged it into Gavin's recent ALTER INDEX
addition.
Many thanks for applying my first patch, but looking at result I noticed
that you have removed INDEX from the list_ALTER which looks like a
possible merge-error to me(Garry added that one in his original patch
and it got removed after you applied mine).
Please correct me if I'm wrong - a small patch for this is attached
I have added your list of uncompleted items to the TODO list.
good idea - I will see if I can fix some of them soon!
Stefan
Index: src/bin/psql/tab-complete.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.111
diff -u -r1.111 tab-complete.c
--- src/bin/psql/tab-complete.c 20 Aug 2004 19:24:59 - 1.111
+++ src/bin/psql/tab-complete.c 20 Aug 2004 22:18:05 -
@@ -647,8 +647,8 @@
{
static const char *const list_ALTER[] =
{"AGGREGATE", "CONVERSATION", "DATABASE","DOMAIN", "FUNCTION",
- "GROUP", "LANGUAGE", "OPERATOR", "SCHEMA", "SEQUENCE", "TABLE",
- "TABLESPACE", "TRIGGER", "TYPE", "USER", NULL};
+ "GROUP", "INDEX", "LANGUAGE", "OPERATOR", "SCHEMA", "SEQUENCE",
+ "TABLE", "TABLESPACE", "TRIGGER", "TYPE", "USER", NULL};
COMPLETE_WITH_LIST(list_ALTER);
}
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[PATCHES] psql tab-complete patch #3
Hi all!
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code.
This diff includes the still missing tab-complete support for TABLESPACE
I already sent earlier.
New in this version of the patch is a small adaption of the tab-complete
code to support the adjusted SAVEPOINT-Syntax commited by Tom, as well
as completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
As I already stated earlier I'm by no means a programmer, and I would
love to get at least some feedback if there is even the slightest
interest in(or since some of the changes may qualify as feature
enhancements, most of this is not 8.0 material).
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE SET
+ too)
*) provide a list of possible indexes following ALTER TABLE CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON + would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
and some random things I noticed that are either still missing or need
some thought:
*) provide a list of conversions after ALTER CONVERSION (?)
*) tabcomplete-support for ALTER SEQUENCE
*) add RENAME TO to ALTER TRIGGER
*) tab-completesupport for ALTER USER
*) fix ALTER (GROUP|DOMAIN|...) DROP - autocomplete
*) RENAME TO support for ALTER LANGUAGE
*) more complete support for COPY
*) more complete ALTER TABLE - support
Stefan
Index: src/bin/psql/tab-complete.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -u -r1.109 tab-complete.c
--- src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
+++ src/bin/psql/tab-complete.c 14 Aug 2004 18:42:11 -
@@ -328,6 +328,10 @@
"SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database "\
" WHERE substring(pg_catalog.quote_ident(datname),1,%d)='%s'"
+#define Query_for_list_of_tablespaces \
+"SELECT pg_catalog.quote_ident(spcname) FROM pg_catalog.pg_tablespace "\
+" WHERE substring(pg_catalog.quote_ident(spcname),1,%d)='%s'"
+
#define Query_for_list_of_encodings \
" SELECT DISTINCT pg_catalog.pg_encoding_to_char(conforencoding) "\
" FROM pg_catalog.pg_conversion "\
@@ -365,6 +369,15 @@
" and pg_catalog.quote_ident(c2.relname)='%s'"\
" and pg_catalog.pg_table_is_visible(c2.oid)"
+/* the silly-looking length condition is just to eat up the current word */
+#define Query_for_index_of_table \
+"SELECT pg_catalog.quote_ident(c2.relname) "\
+" FROM pg_catalog.pg_class c1, pg_catalog.pg_class c2, pg_catalog.pg_index i"\
+" WHERE c1.oid=i.indrelid and i.indexrelid=c2.oid"\
+" and (%d = length('%s'))"\
+" and pg_catalog.quote_ident(c1.relname)='%s'"\
+" and pg_catalog.pg_table_is_visible(c2.oid)"
+
/*
* This is a list of all "things" in Pgsql, which can show up after CREATE or
* DROP; and there is also a query to get a list of them.
@@ -394,6 +407,7 @@
{"SCHEMA", Query_for_list_of_schemas},
{"SEQUENCE", NULL, &Query_for_list_of_sequences},
{"TABLE", NULL, &Query_for_list_of_tables},
+ {"TABLESPACE", Query_for_list_of_tablespaces},
{"TEMP", NULL, NULL}, /* for CREATE TEMP TABLE ... */
{"TRIGGER", "SELECT pg_catalog.quote_ident(tgname) FROM pg_catalog.pg_trigger
WHERE substring(pg_catalog.quote_ident(tgname),1,%d)='%s'"},
{"TYPE", NULL, &Query_for_list_of_datatypes},
@@ -461,7 +475,7 @@
static const char * const sql_commands[] = {
"ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE",
"CLUSTER", "COMMENT",
- "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE", "DELETE", "DROP",
"EXECUTE",
+ "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE", "DELETE", "DROP",
"END", "EXECUTE",
"EXPLA
Re: [PATCHES] ALTER INDEX
Gavin Sherry wrote:
Index: src/bin/psql/tab-complete.c
===
RCS file: /usr/local/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -2 -c -r1.109 tab-complete.c
*** src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
--- src/bin/psql/tab-complete.c 13 Aug 2004 06:34:55 -
***
*** 633,637
{
static const char *const list_ALTER[] =
! {"DATABASE", "GROUP", "SCHEMA", "TABLE", "TRIGGER", "USER", NULL};
COMPLETE_WITH_LIST(list_ALTER);
--- 633,638
{
static const char *const list_ALTER[] =
! {"DATABASE", "GROUP", "SCHEMA", "TABLE", "TRIGGER", "USER", "INDEX",
! NULL};
COMPLETE_WITH_LIST(list_ALTER);
***
*** 647,650
--- 648,661
COMPLETE_WITH_LIST(list_ALTERDATABASE);
}
+ /* ALTER INDEX */
+ else if (pg_strcasecmp(prev3_wd, "ALTER") == 0 &&
+ pg_strcasecmp(prev2_wd, "INDEX") == 0)
+ {
+ static const char *const list_ALTERDATABASE[] =
+ {"SET TABLESPACE", "OWNER TO", "RENAME TO", NULL};
+
+ COMPLETE_WITH_LIST(list_ALTERDATABASE);
minor issue/nit(?): reusing list_ALTERDATABASE for the ALTER INDEX part
looks a little strange ...
Stefan(who could really need some feedback on his own tab-complete patch
*g*)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] psql - missing tab-completion support for tablespaces
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
When looking through the code I found that there seem to be much more
places where the tabcomplete-code is not 100% in sync with what the
doc's show as possible syntax.
Is there interest in fixing those up (ie qualifing as BUGS that can get
fixed during BETA) ? If so I could take a look at those in the next days ...
Yes, please send in any tab completion improvements you can make.
Hi!
attached is a patch that adds/fixes several smaller things in the
psql-tabcomplete code. This diff inculdes the TABLESPACE tab-complete
patches I sent earlier.
Since we are in Beta now and I'm by no means a programmer, I want to
know if this is something that is needed - or if I'm completely off-way
with what I'm doing here and wasting your and my time ...
below is a list of the things I have changed with this patch.
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users in every occurence of "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE SET
+ too)
*) provide a list of possible indexes following ALTER TABLE CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON + would produce CLUSTER ON ON - same for TRIGGER ON)
and some random things I noticed that are either still missing or need
some thought:
*) provide a list of conversions after ALTER CONVERSION (?)
*) tabcomplete-support for ALTER SEQUENCE
*) add RENAME TO to ALTER TRIGGER
*) add OWNER TO to ALTER TYPE
*) tab-completesupport for ALTER USER
*) fix ALTER (GROUP|DOMAIN|...) DROP - autocomplete
*) RENAME TO support for ALTER LANGUAGE
*) more complete support for COPY
*) more complete ALTER TABLE - support
Stefan
Index: src/bin/psql/tab-complete.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -u -r1.109 tab-complete.c
--- src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
+++ src/bin/psql/tab-complete.c 10 Aug 2004 08:24:18 -
@@ -328,6 +328,10 @@
"SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database "\
" WHERE substring(pg_catalog.quote_ident(datname),1,%d)='%s'"
+#define Query_for_list_of_tablespaces \
+"SELECT pg_catalog.quote_ident(spcname) FROM pg_catalog.pg_tablespace "\
+" WHERE substring(pg_catalog.quote_ident(spcname),1,%d)='%s'"
+
#define Query_for_list_of_encodings \
" SELECT DISTINCT pg_catalog.pg_encoding_to_char(conforencoding) "\
" FROM pg_catalog.pg_conversion "\
@@ -365,6 +369,15 @@
" and pg_catalog.quote_ident(c2.relname)='%s'"\
" and pg_catalog.pg_table_is_visible(c2.oid)"
+/* the silly-looking length condition is just to eat up the current word */
+#define Query_for_index_of_table \
+"SELECT pg_catalog.quote_ident(c2.relname) "\
+" FROM pg_catalog.pg_class c1, pg_catalog.pg_class c2, pg_catalog.pg_index i"\
+" WHERE c1.oid=i.indrelid and i.indexrelid=c2.oid"\
+" and (%d = length('%s'))"\
+" and pg_catalog.quote_ident(c1.relname)='%s'"\
+" and pg_catalog.pg_table_is_visible(c2.oid)"
+
/*
* This is a list of all "things" in Pgsql, which can show up after CREATE or
* DROP; and there is also a query to get a list of them.
@@ -394,6 +407,7 @@
{"SCHEMA", Query_for_list_of_schemas},
{"SEQUENCE", NULL, &Query_for_list_of_sequences},
{"TABLE", NULL, &Query_for_list_of_tables},
+ {"TABLESPACE", Query_for_list_of_tablespaces},
{"TEMP", NULL, NULL}, /* for CREATE TEMP TABLE ... */
{"TRIGGER", "SELECT pg_catalog.quote_ident(tgname) FROM pg_catalog.pg_trigger
WHERE substring(pg_catalog.quote_ident(tgname),1,%d)='%s'"},
{"TYPE", NULL, &
[PATCHES] psql - missing tab-completion support for tablespaces
Hi!
While playing around with 8.0devel I found it somewhat irritating that
psql had no tab-complete support for all tablespace related commands.
Attached is my own poor attempt that adds at least basic support for
CREATE/ALTER/DROP and \db.
When looking through the code I found that there seem to be much more
places where the tabcomplete-code is not 100% in sync with what the
doc's show as possible syntax.
Is there interest in fixing those up (ie qualifing as BUGS that can get
fixed during BETA) ? If so I could take a look at those ...
Stefan
Index: src/bin/psql/tab-complete.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -u -r1.109 tab-complete.c
--- src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
+++ src/bin/psql/tab-complete.c 6 Aug 2004 19:52:52 -
@@ -328,6 +328,10 @@
"SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database "\
" WHERE substring(pg_catalog.quote_ident(datname),1,%d)='%s'"
+#define Query_for_list_of_tablespaces \
+"SELECT pg_catalog.quote_ident(spcname) FROM pg_catalog.pg_tablespace "\
+" WHERE substring(pg_catalog.quote_ident(spcname),1,%d)='%s'"
+
#define Query_for_list_of_encodings \
" SELECT DISTINCT pg_catalog.pg_encoding_to_char(conforencoding) "\
" FROM pg_catalog.pg_conversion "\
@@ -394,6 +398,7 @@
{"SCHEMA", Query_for_list_of_schemas},
{"SEQUENCE", NULL, &Query_for_list_of_sequences},
{"TABLE", NULL, &Query_for_list_of_tables},
+ {"TABLESPACE", Query_for_list_of_tablespaces},
{"TEMP", NULL, NULL}, /* for CREATE TEMP TABLE ... */
{"TRIGGER", "SELECT pg_catalog.quote_ident(tgname) FROM pg_catalog.pg_trigger
WHERE substring(pg_catalog.quote_ident(tgname),1,%d)='%s'"},
{"TYPE", NULL, &Query_for_list_of_datatypes},
@@ -575,9 +580,9 @@
static const char * const backslash_commands[] = {
"\\a", "\\connect", "\\C", "\\cd", "\\copy", "\\copyright",
- "\\d", "\\da", "\\dc", "\\dC", "\\dd", "\\dD", "\\df", "\\dg", "\\di",
- "\\dl", "\\dn", "\\do", "\\dp", "\\ds", "\\dS", "\\dt", "\\dT",
- "\\dv", "\\du",
+ "\\d", "\\da", "\\db", "\\dc", "\\dC", "\\dd", "\\dD", "\\df",
+ "\\dg", "\\di", "\\dl", "\\dn", "\\do", "\\dp", "\\ds", "\\dS",
+ "\\dt", "\\dT", "\\dv", "\\du",
"\\e", "\\echo", "\\encoding",
"\\f", "\\g", "\\h", "\\help", "\\H", "\\i", "\\l",
"\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink",
@@ -632,7 +637,7 @@
pg_strcasecmp(prev3_wd, "TABLE") != 0)
{
static const char *const list_ALTER[] =
- {"DATABASE", "GROUP", "SCHEMA", "TABLE", "TRIGGER", "USER", NULL};
+ {"DATABASE", "GROUP", "SCHEMA", "TABLE", "TABLESPACE", "TRIGGER",
"USER", NULL};
COMPLETE_WITH_LIST(list_ALTER);
}
@@ -691,6 +696,16 @@
pg_strcasecmp(prev2_wd, "DROP") == 0 &&
pg_strcasecmp(prev_wd, "COLUMN") == 0)
COMPLETE_WITH_ATTR(prev3_wd);
+
+ /* we have ALTER TABLESPACE, so suggest RENAME TO, OWNER TO */
+ else if (pg_strcasecmp(prev3_wd, "ALTER") == 0 &&
+pg_strcasecmp(prev2_wd, "TABLESPACE") == 0)
+ {
+ static const char *const list_ALTERTSPC[] =
+ {"RENAME TO", "OWNER TO", NULL};
+
+ COMPLETE_WITH_LIST(list_ALTERTSPC);
+ }
/* complete ALTER GROUP with ADD or DROP */
else if (pg_strcasecmp(prev3_wd, "ALTER") == 0 &&
@@ -985,7 +1000,8 @@
" UNION SELECT
'DATABASE'"
" UNION SELECT
'FUNCTION'"
" UNION SELECT
'LANGUAGE'"
- " UNION SELECT
'SCHEMA'");
+ " UNION SELECT
'SCHEMA'"
+ " UNION SELECT
'TABLESPACE'");
/* Complete "GRANT/REVOKE * ON * " with "TO" */
else if ((pg_strcasecmp(prev4_wd, "GRANT") == 0 ||
@@ -1000,6 +1016,8 @@
COMPLETE_WITH_QUERY(Query_for_list_of_languages);
else if (pg_strcasecmp(prev_wd, "SCHEMA") == 0)
COMPLETE_WITH_QUERY(Query_for_list_of_schemas);
+ else if (pg_strcasecmp(prev_wd, "TABLESPACE") == 0)
+ COMPLETE_WITH_QUERY(Query_for_list_of_tablespaces);
else
COMPLETE_WITH_CONST("TO");
}
@@ -1007,7 +1025,7 @@
/*
* TODO: to complete with user name we need prev5_w
[PATCHES] psql - missing tab-completion support for tablespaces
[sorry if you get this mail twice, i think my first post didn't made it
passt the moderator queue]
Hi!
While playing around with 8.0devel I found it somewhat irritating that
psql had no tab-complete support for all tablespace related commands.
Attached is my own poor attempt that adds at least basic support for
CREATE/ALTER/DROP and \db.
When looking through the code I found that there seem to be much more
places where the tabcomplete-code is not 100% in sync with what the
doc's show as possible syntax.
Is there interest in fixing those up (ie qualifing as BUGS that can get
fixed during BETA) ? If so I could take a look at those in the next days ...
Stefan
Index: src/bin/psql/tab-complete.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -u -r1.109 tab-complete.c
--- src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
+++ src/bin/psql/tab-complete.c 6 Aug 2004 19:52:52 -
@@ -328,6 +328,10 @@
"SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database "\
" WHERE substring(pg_catalog.quote_ident(datname),1,%d)='%s'"
+#define Query_for_list_of_tablespaces \
+"SELECT pg_catalog.quote_ident(spcname) FROM pg_catalog.pg_tablespace "\
+" WHERE substring(pg_catalog.quote_ident(spcname),1,%d)='%s'"
+
#define Query_for_list_of_encodings \
" SELECT DISTINCT pg_catalog.pg_encoding_to_char(conforencoding) "\
" FROM pg_catalog.pg_conversion "\
@@ -394,6 +398,7 @@
{"SCHEMA", Query_for_list_of_schemas},
{"SEQUENCE", NULL, &Query_for_list_of_sequences},
{"TABLE", NULL, &Query_for_list_of_tables},
+ {"TABLESPACE", Query_for_list_of_tablespaces},
{"TEMP", NULL, NULL}, /* for CREATE TEMP TABLE ... */
{"TRIGGER", "SELECT pg_catalog.quote_ident(tgname) FROM pg_catalog.pg_trigger
WHERE substring(pg_catalog.quote_ident(tgname),1,%d)='%s'"},
{"TYPE", NULL, &Query_for_list_of_datatypes},
@@ -575,9 +580,9 @@
static const char * const backslash_commands[] = {
"\\a", "\\connect", "\\C", "\\cd", "\\copy", "\\copyright",
- "\\d", "\\da", "\\dc", "\\dC", "\\dd", "\\dD", "\\df", "\\dg", "\\di",
- "\\dl", "\\dn", "\\do", "\\dp", "\\ds", "\\dS", "\\dt", "\\dT",
- "\\dv", "\\du",
+ "\\d", "\\da", "\\db", "\\dc", "\\dC", "\\dd", "\\dD", "\\df",
+ "\\dg", "\\di", "\\dl", "\\dn", "\\do", "\\dp", "\\ds", "\\dS",
+ "\\dt", "\\dT", "\\dv", "\\du",
"\\e", "\\echo", "\\encoding",
"\\f", "\\g", "\\h", "\\help", "\\H", "\\i", "\\l",
"\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink",
@@ -632,7 +637,7 @@
pg_strcasecmp(prev3_wd, "TABLE") != 0)
{
static const char *const list_ALTER[] =
- {"DATABASE", "GROUP", "SCHEMA", "TABLE", "TRIGGER", "USER", NULL};
+ {"DATABASE", "GROUP", "SCHEMA", "TABLE", "TABLESPACE", "TRIGGER",
"USER", NULL};
COMPLETE_WITH_LIST(list_ALTER);
}
@@ -691,6 +696,16 @@
pg_strcasecmp(prev2_wd, "DROP") == 0 &&
pg_strcasecmp(prev_wd, "COLUMN") == 0)
COMPLETE_WITH_ATTR(prev3_wd);
+
+ /* we have ALTER TABLESPACE, so suggest RENAME TO, OWNER TO */
+ else if (pg_strcasecmp(prev3_wd, "ALTER") == 0 &&
+pg_strcasecmp(prev2_wd, "TABLESPACE") == 0)
+ {
+ static const char *const list_ALTERTSPC[] =
+ {"RENAME TO", "OWNER TO", NULL};
+
+ COMPLETE_WITH_LIST(list_ALTERTSPC);
+ }
/* complete ALTER GROUP with ADD or DROP */
else if (pg_strcasecmp(prev3_wd, "ALTER") == 0 &&
@@ -985,7 +1000,8 @@
" UNION SELECT
'DATABASE'"
" UNION SELECT
'FUNCTION'"
" UNION SELECT
'LANGUAGE'"
- " UNION SELECT
'SCHEMA'");
+ " UNION SELECT
'SCHEMA'"
+ " UNION SELECT
'TABLESPACE'");
/* Complete "GRANT/REVOKE * ON * " with "TO" */
else if ((pg_strcasecmp(prev4_wd, "GRANT") == 0 ||
@@ -1000,6 +1016,8 @@
COMPLETE_WITH_QUERY(Query_for_list_of_languages);
else if (pg_strcasecmp(prev_wd, "SCHEMA") == 0)
COMPLETE_WITH_QUERY(Query_for_list_of_schemas);
+ else if (pg_strcasecmp(prev_wd, "TABLESPACE") == 0)
+ COMPLETE_WITH_QUERY(Query_for_list_of_tablespaces);
else
COMPLETE_WITH_CONS
Re: [PATCHES] add missing options to pg_dumpall
Bruce Momjian wrote:
Patch applied. Thanks.
thanks - that's wonderful news :-)
However the patch as it went in has a minor cosmetic issues with the
display of the --help output.
Maybe something like the attached patch should be applied to restore
the alphabetical option ordering and make the output more like the
pg_dump output.
Stefan
Index: src/bin/pg_dump/pg_dumpall.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dumpall.c,v
retrieving revision 1.44
diff -u -r1.44 pg_dumpall.c
--- src/bin/pg_dump/pg_dumpall.c12 Jul 2004 14:35:45 - 1.44
+++ src/bin/pg_dump/pg_dumpall.c14 Jul 2004 17:56:04 -
@@ -310,26 +310,26 @@
printf(_("Usage:\n"));
printf(_(" %s [OPTION]...\n"), progname);
- printf(_("\nOptions:\n"));
+ printf(_("\nGeneral options:\n"));
+ printf(_(" -i, --ignore-version proceed even when server version
mismatches\n"
+" pg_dumpall version\n"));
+ printf(_(" --help show this help, then exit\n"));
+ printf(_(" --versionoutput version information, then
exit\n"));
+ printf(_("\nOptions controlling the output content:\n"));
printf(_(" -a, --data-only dump only the data, not the schema\n"));
printf(_(" -c, --clean clean (drop) databases prior to
create\n"));
printf(_(" -d, --insertsdump data as INSERT, rather than COPY,
commands\n"));
printf(_(" -D, --column-inserts dump data as INSERT commands with column
names\n"));
printf(_(" -g, --globals-only dump only global objects, no
databases\n"));
- printf(_(" -i, --ignore-version proceed even when server version
mismatches\n"
-" pg_dumpall version\n"));
- printf(_(" -s, --schema-onlydump only the schema, no data\n"));
- printf(_(" -S, --superuser=NAME specify the superuser user name to use in
the dump\n"));
printf(_(" -o, --oids include OIDs in dump\n"));
printf(_(" -O, --no-owner do not output commands to set object
ownership\n"));
- printf(_(" -v, --verboseverbose mode\n"));
+ printf(_(" -s, --schema-onlydump only the schema, no data\n"));
+ printf(_(" -S, --superuser=NAME specify the superuser user name to use in
the dump\n"));
printf(_(" -x, --no-privileges do not dump privileges
(grant/revoke)\n"));
printf(_(" -X disable-dollar-quoting, --disable-dollar-quoting\n"
" disable dollar quoting, use SQL
standard quoting\n"));
printf(_(" -X disable-triggers, --disable-triggers\n"
-" disable triggers during data-only
restore\n"));
- printf(_(" --help show this help, then exit\n"));
- printf(_(" --versionoutput version information, then
exit\n"));
+" disable triggers during data-only
restore\n"));
printf(_("\nConnection options:\n"));
printf(_(" -h, --host=HOSTNAME database server host or socket
directory\n"));
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
