Re: [PATCHES] initdb authentication
Patch applied. Thanks. I just cleaned up some of the code formatting. --- Magnus Hagander wrote: Ok, here is another one. Doc patches coming up if/when this one is approved. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: den 17 juli 2004 03:11 To: Magnus Hagander Cc: [EMAIL PROTECTED] Subject: Re: [PATCHES] initdb authentication I got a new idea on this. I think we should add an initdb option that takes a string to specify the local authentication method: initdb --localauth 'ident' or whatever the user wants. I think this is more flexible and more compact. It would default to 'trust', and the packagers could set it to whatever they want. If their OS supports local ident, they can use that. Also keep in mind you might want some ident map file: initdb --localauth 'ident mymap' so you would need to allow multiple words in the string. --- Magnus Hagander wrote: Here's a version of this patch that includes documentation updates. //Magnus Content-Description: initdb_auth.patch [ Attachment, skipping... ] -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
Patch applied. Thanks. I made small adjustment for configure. --- Andrew Dunstan wrote: Bruce Momjian wrote: Andrew Dunstan wrote: I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. One question --- why is there a sleep loop needed for unlink in your patch? We will just be calling the existing pgunlink() (which has a sleep) in the Windows cases, so this question becomes moot. Great. Thanks. Sorry I delayed addressing this for so long. Please check the enclosed patch to see if it does what you want. Should we look at replacing cp/copy in 7.6? probably. Put it as a possible TODO maybe. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pg_config
Patch applied. Thanks. I made all the changes you suggested and the additions to path.c for the new parameters. --- Andrew Dunstan wrote: There are a couple of things that need adjustment: 1. typo in the makefile - ((X) should be $(X) 2. these cases need to be fixed: else if (strcmp(argv[i],--includedir-server) ==0) get_pkginclude_path(mypath,otherpath); else if (strcmp(argv[i],--libdir) == 0) get_include_path(mypath,otherpath); We might actually need one or two functions in port/path.c to handle them. cheers andrew Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] String consistency
Hackers,
This little patch reworks some strings that were already present in 7.4
with a minor difference.
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
La persona que no quería pecar / estaba obligada a sentarse
en duras y empinadas sillas/ desprovistas, por cierto
de blandos atenuantes (Patricio Vogel)
Index: access/transam/xlog.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xlog.c,v
retrieving revision 1.152
diff -c -r1.152 xlog.c
*** access/transam/xlog.c 22 Jul 2004 21:09:37 - 1.152
--- access/transam/xlog.c 1 Aug 2004 03:43:37 -
***
*** 1936,1942
if (unlink(xlogpath) != 0)
ereport(FATAL,
(errcode_for_file_access(),
!errmsg(could not remove \%s\: %m,
xlogpath)));
}
--- 1936,1942
if (unlink(xlogpath) != 0)
ereport(FATAL,
(errcode_for_file_access(),
!errmsg(could not remove file \%s\: %m,
xlogpath)));
}
***
*** 3772,3778
if (rename(recoveryPath, xlogpath) != 0)
ereport(FATAL,
(errcode_for_file_access(),
!errmsg(could not rename \%s\ to \%s\:
%m,
recoveryPath, xlogpath)));
/* XXX might we need to fix permissions on the file? */
}
--- 3772,3778
if (rename(recoveryPath, xlogpath) != 0)
ereport(FATAL,
(errcode_for_file_access(),
!errmsg(could not rename file \%s\ to
\%s\: %m,
recoveryPath, xlogpath)));
/* XXX might we need to fix permissions on the file? */
}
***
*** 3814,3820
if (rename(recoveryCommandFile, recoveryCommandDone) != 0)
ereport(FATAL,
(errcode_for_file_access(),
!errmsg(could not rename \%s\ to \%s\: %m,
recoveryCommandFile,
recoveryCommandDone)));
ereport(LOG,
--- 3814,3820
if (rename(recoveryCommandFile, recoveryCommandDone) != 0)
ereport(FATAL,
(errcode_for_file_access(),
!errmsg(could not rename file \%s\ to \%s\: %m,
recoveryCommandFile,
recoveryCommandDone)));
ereport(LOG,
Index: postmaster/pgarch.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/postmaster/pgarch.c,v
retrieving revision 1.2
diff -c -r1.2 pgarch.c
*** postmaster/pgarch.c 21 Jul 2004 22:31:22 - 1.2
--- postmaster/pgarch.c 1 Aug 2004 03:44:14 -
***
*** 587,592
if (rename(rlogready, rlogdone) 0)
ereport(WARNING,
(errcode_for_file_access(),
!errmsg(could not rename \%s\ to \%s\: %m,
rlogready, rlogdone)));
}
--- 587,592
if (rename(rlogready, rlogdone) 0)
ereport(WARNING,
(errcode_for_file_access(),
!errmsg(could not rename file \%s\ to \%s\: %m,
rlogready, rlogdone)));
}
Index: postmaster/postmaster.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.417
diff -c -r1.417 postmaster.c
*** postmaster/postmaster.c 31 Jul 2004 00:45:33 - 1.417
--- postmaster/postmaster.c 1 Aug 2004 06:30:48 -
***
*** 544,550
if (!guc_pgdata)/* Got a pgdata from the config file? */
{
write_stderr(%s does not know where to find the database
system data.\n
!This should be specified as 'pgdata'
in %s%s.\n,
progname, userPGDATA,
user_pgconfig_is_dir ?
/postgresql.conf : );
ExitPostmaster(2);
--- 544,550
if (!guc_pgdata)/* Got a pgdata from the config file? */
{
Re: [PATCHES] pg_config
Bruce Momjian wrote: Patch applied. Thanks. I made all the changes you suggested and the additions to path.c for the new parameters. I think you forgot to commit the new source files. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pg_config
Bruce Momjian wrote: Oops, sorry, done. The --pgxs option seems to have gotten lost in the conversion. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pg_config
Peter Eisentraut wrote: Bruce Momjian wrote: Oops, sorry, done. The --pgxs option seems to have gotten lost in the conversion. It wasn't there when I did the conversion. Usual problem of duelling patches. Can you fix it, or do you need me to send in a patch? cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Random regression failures
Bruce Momjian [EMAIL PROTECTED] writes: I am seeing random parallel regression failures. I would say 20% of the time I see a failure on the regression test. It has happened several times to me in the past few days. Regression diff attached. A stack trace and/or postmaster log report of the crashing process would be considerably more useful (and less bulky) than this. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [subxacts] Last try before beta
Alvaro Herrera [EMAIL PROTECTED] writes: Here is the last patch before beta for subtransactions. It fixes the following outstanding issues: Applied with revisions. I had to whack around the code associated with the subtrans XID cache, because it was seriously violating the locking requirements for addition/removal of running XIDs in PGPROC (see the comments in GetSnapshotData, GetNewTransactionId, CommitTransaction). It's possible that for subxact XIDs we need not be quite so tense, but I would rather be conservative now and consider optimizations later. - Update comments in code, htup.h and xact.c The update in xact.c seemed to consist of wholesale removal of the top comment. I didn't apply it, because the comment didn't seem that useless. It does need editorial work, but it's not content-free... - SetReindexProcessing On this it seemed better to make use of TRY/CATCH to reset the flag instead of putting the burden on xact.c. Now that we have TRY/CATCH I think we should make an effort to do things that way where possible. Note that I deliberately broke the API for EOXactCallbacks, because something that needs to do something at that low a level surely needs to be at least revised to check if it's OK regarding subtransactions. Agreed. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] String consistency
Alvaro Herrera [EMAIL PROTECTED] writes: This little patch reworks some strings that were already present in 7.4 with a minor difference. Applied. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES]Traditional Chinese translations in UTF-8 for 7.5
Zhenbang Wei wrote: Using UTF-8 instead of anonying Big5. Sorry for causing problems. Installed. Whatever works for you is OK. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [subxacts] Last try before beta
On Sun, Aug 01, 2004 at 01:41:39PM -0400, Tom Lane wrote: - Update comments in code, htup.h and xact.c The update in xact.c seemed to consist of wholesale removal of the top comment. I didn't apply it, because the comment didn't seem that useless. It does need editorial work, but it's not content-free... Well, the README file integrated those comments as appropiate. Apparently the embed-new-files-in-patch business was not a good idea after all. Sorry for not being clear on the message. Again, thanks for all your excellent work on this. Oh, I was wondering whether it would be a good idea to move tqual.c to access/transam. I think it's weird in utils/time, and do we really want a directory for just one file that's even badly placed according to the comments on the file itself? -- Alvaro Herrera ([EMAIL PROTECTED]) Y eso te lo doy firmado con mis lágrimas (Fiebre del Loco) ---(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] [subxacts] Last try before beta
Alvaro Herrera [EMAIL PROTECTED] writes: Well, the README file integrated those comments as appropiate. Oh... Apparently the embed-new-files-in-patch business was not a good idea after all. Sorry for not being clear on the message. Yeah. I can deal with 'cvs diff' stuff but it wasn't at all clear that this patch was adding files. Could you send me just the README (off list)? Oh, I was wondering whether it would be a good idea to move tqual.c to access/transam. I think it's weird in utils/time, and do we really want a directory for just one file that's even badly placed according to the comments on the file itself? It's not worth the loss of CVS history to move it ... and I'm not sure that access/transam is a better place anyway. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Fix for OWNER TO breaking ACLs
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Attached is a patch that fixes the owner change command on objects that have privileges. Applied with revisions. Just FYI --- * The aclnewowner code wasn't really right at all. It was changing ai_grantee without checking whether that value was a UID, GID, or WORLD; and it was not adequately handling the problem of merging duplicate entries afterwards. (You have to think about entries with the new owner as grantor as well as such entries with grantee; and even considering only the grantee case, it's wrong to suppose there can be only one.) I replaced the logic with a general-purpose search for duplicate entries, which might be overkill but it will reliably get the right answer. * You had consistently changed the simple_heap_update calls to do the wrong thing. (I'm surprised it didn't blow up on you in your testing.) In a sequence like newtuple = heap_modifytuple(tup, rel, repl_val, repl_null, repl_repl); simple_heap_update(rel, newtuple-t_self, newtuple); CatalogUpdateIndexes(rel, newtuple); the second parameter to simple_heap_update *must* be newtuple-t_self not tup-t_self. The reason is that simple_heap_update stores the new physical location of the updated tuple back into that parameter, and then the CatalogUpdateIndexes call relies on newtuple-t_self to generate new index entries. The way you had it coded, it was generating new index entries pointing at the old version of the tuple ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] fix schema ownership on first connection preliminary patch v2
Bruce Momjian [EMAIL PROTECTED] writes: Fabien COELHO wrote: Please find attached a preliminary patch to fix schema ownership on first connection. It is for comments and advices as I still have doubts about various how-and-where issues, thus it is not submitted to the patch list. I have added the v2 version of this patch to the patch queue (attached). I do apologize for not having looked at this patch sooner, but it's been at the bottom of the priority queue :-( In general I do not like the approach of using SPI for this, because it has to execute before the system is really quite fully up. Just looking at InitPostgres, I note that the namespace search path isn't set yet, for example, and I'm not real sure what that implies for execution of these queries. I'm also uncomfortable with the fact that RelationCacheInitializePhase3 isn't done yet --- the SPI execution could pollute the relcache with stuff we don't really want written into the relcache cache file. (Much of this could be dodged by having ReverifyMyDatabase just pass back the datinit flag, and then taking action on it (if any) at the bottom of InitPostgres instead of where the patch puts it. But I'm still against using SPI for it.) Also, since we already have AlterSchemaOwner coded at the C level, the original rationale of not wanting to add code has been rendered moot. I do not like the hardwired assumption that userID 1 exists and is a superuser. The code is also broken to assume that ID 1 is the owner of the public schema in the source database (though this part is at least easy to fix, and would go away anyway if using AlterSchemaOwner). Lastly, I'm unconvinced that the (lack of) locking is safe. Two backends trying to connect at the same time would make conflicting attempts to UPDATE pg_database, and if the default transaction isolation mode is SERIALIZABLE then one of them is going to get an actual failure, not just decide it has nothing to do. A possible alternative is to take out ExclusiveLock on pg_namespace before re-examining pg_database. However, enough about implementation deficiencies. Did we really have consensus that the system should do this in the first place? I was only about halfway sold on the notion of changing public's ownership. I especially dislike the detail that it will alter the ownership of *all* non-builtin schemas, not only public. If someone has added special-purpose schemas to template1, it seems unlikely that this is the behavior they'd want. I'm also wondering about what side-effects this will have on pg_dump behavior. In particular, will pg_dump try to ALTER OWNER public, and if so will that be appropriate? We haven't previously needed to assume that we are restoring into a database with the same datowner as we dumped from... I think we should leave the behavior alone, at least for this release cycle. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Random regression failures
Bruce Momjian [EMAIL PROTECTED] writes: I am seeing random parallel regression failures. I would say 20% of the time I see a failure on the regression test. FWIW, my other machine has been running repeated parallel regress tests for several hours. It's now up to 130 completed cycles with no failures (except one that I deliberately induced to make sure the shell script would notice...) This is a clean build from a CVS pull at about 14:30 EDT today. All parameters default except for configure --enable-debug --enable-cassert regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] win32 version info - try 2
I took the ai file, reduced it to the right sizes in photoshop and used an icon editor to make it at various resolutions. Gavin On Sun, 1 Aug 2004 00:25:55 +0200, Magnus Hagander [EMAIL PROTECTED] wrote: It's platform specific, therefor it should go in port/. The criterion for port/ is not whether something is platform-specific. It's whether it's a module that helps porting source code. Which this is not. Maybe we should add a new directory that contains icons and other random auxiliary files such as .desktop files for Linux desktops. Sure, that works for me. It's a simple path change in Makefile.global.in. So whatever works for you guys. Is it the concept of non-sourcecode, or is it the fact that it's actually binary that is the issue? E.g. will it help if we for example uuencoded it and then just uudecode:ed it in a build rule? The problem isn't so much binary files vs. CVS, although that is an annoyance to take into account. The issue is that we need to have the source code for all files that we distribute, where source code is the preferred form for modification. This is a legal issue, a philosophical issue, and a practical issue. If you say the icon is created by hand, then that's OK, although up to now I've created all icons programmatically from, say, a PNG or SVG source. Well, what I did was, as I wrote in my original mail, download it from http://pgsql.gavinroy.com/art/. AFAIK the original source of it is a ..ai file, though. I'll have to ask Gavin about how the file was actually created, it if twas done manually or through an automatable process. Gavin - hopefully you can say something on how it's done? Thanks. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] pg_ctl -o option dumps core when processing postmaster arguments...
The attached space adds '\0' as a whitespace character and prevents pg_ctl from running out of bounds when processing arguments for -o. I don't think this ever worked, at least on Mac, but I suspect every platform suffered from this bug. % gdb ./bin/pg_ctl GNU gdb 5.3-20030128 (Apple version gdb-309) (Thu Dec 4 15:41:30 GMT 2003) This GDB was configured as powerpc-apple-darwin. Reading symbols for shared libraries done (gdb) set arg -w -o -F start (gdb) run Starting program: /usr/local/pgsql/bin/pg_ctl -w -o -F start Reading symbols for shared libraries ++.. done waiting for postmaster to start... Program received signal EXC_BAD_ACCESS, Could not access memory. test_postmaster_connection () at pg_ctl.c:363 363 p++; (gdb) bt #0 test_postmaster_connection () at pg_ctl.c:363 #1 0x3594 in do_start () at pg_ctl.c:539 #2 0x3594 in do_start () at pg_ctl.c:539 #3 0x4874 in main (argc=-1610604968, argv=0x0) at pg_ctl.c:1360 (gdb) p *p $1 = 0 '\0' -sc Index: pg_ctl.c === RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_ctl/pg_ctl.c,v retrieving revision 1.23 diff -u -r1.23 pg_ctl.c --- pg_ctl.c22 Jul 2004 01:44:36 - 1.23 +++ pg_ctl.c26 Jul 2004 18:53:52 - @@ -30,7 +30,7 @@ #define _(x) gettext((x)) -#define WHITESPACE \f\n\r\t\v/* as defined by isspace() */ +#define WHITESPACE \f\n\r\t\v\0 /* as defined by isspace() */ /* postmaster version ident string */ #define PM_VERSIONSTR postmaster (PostgreSQL) PG_VERSION \n -- Sean Chittenden ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32 version info - try 2
On Sat, Jul 31, 2004 at 05:40:34PM -0700, Gavin M. Roy wrote: I took the ai file, reduced it to the right sizes in photoshop and used an icon editor to make it at various resolutions. Can this be done programatically using, say, ImageMagick? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The West won the world not by the superiority of its ideas or values or religion but rather by its superiority in applying organized violence. Westerners often forget this fact, non-Westerners never do. (Samuel P. Huntington) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] UTF8 for all translations?
On Sun, 1 Aug 2004 [EMAIL PROTECTED] wrote: Date: Sun, 01 Aug 2004 02:40:12 -0300 Date: Sun, 1 Aug 2004 13:31:08 +0800 From: Zhenbang Wei [EMAIL PROTECTED] Subject: Traditional Chinese translations in UTF-8 for 7.5 Using UTF-8 instead of anonying Big5. Sorry for causing problems. Why not to use UTF8 fot all .po file for consistency (and to possibly avoid future problems like that)? Take a look at pgAdmin III as an example. Thanks. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES]Traditional Chinese initdb-zh_TW.po for 7.5
3 new messages translated. initdb-zh_TW.po Description: Binary data ---(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] fix for parameterized queries in DECLARE CURSOR statements
Oliver Jowett [EMAIL PROTECTED] writes: Here's a patch that allows parameterized queries to be used in a DECLARE CURSOR statement. Applied with minor editorialization. I found a couple of places where you'd missed inserting type Oids into constructed ParamLists, and I took advantage of the extra info to add Asserts checking that the value found in a ParamList is in fact what the caller expects. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] fix schema ownership on first connection preliminary
I'm also wondering about what side-effects this will have on pg_dump behavior. In particular, will pg_dump try to ALTER OWNER public, and if so will that be appropriate? We haven't previously needed to assume that we are restoring into a database with the same datowner as we dumped from... In my batch of pg_dump patches that have gone in, pg_dump will now do exactly that. The reason was so that if someone altered the owner of their public schema, it should be dumped like that. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Fix for OWNER TO breaking ACLs
* You had consistently changed the simple_heap_update calls to do the wrong thing. (I'm surprised it didn't blow up on you in your testing.) In a sequence like newtuple = heap_modifytuple(tup, rel, repl_val, repl_null, repl_repl); simple_heap_update(rel, newtuple-t_self, newtuple); CatalogUpdateIndexes(rel, newtuple); the second parameter to simple_heap_update *must* be newtuple-t_self not tup-t_self. The reason is that simple_heap_update stores the new physical location of the updated tuple back into that parameter, and then the CatalogUpdateIndexes call relies on newtuple-t_self to generate new index entries. The way you had it coded, it was generating new index entries pointing at the old version of the tuple ... Strange. I guess I must have been testing with a database that had short enough system catalogs that the indexes were never used? Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] USING INDEX TABLESPACE
Christopher Kings-Lynne [EMAIL PROTECTED] writes: The attached patch allows the specification of the tablespace the index is to be created in for unique and pk constraints. It also fixes the dumping of such constraints so that they are restored into the correct tablespace, after they have been moved with SET TABLESPACE. This is currently an outstanding pg_dump bug. Applied. I also added some code to ruleutils.c to make pg_get_constraintdef output the USING INDEX TABLESPACE clause at need. We might want to think about getting pg_dump to rely more on pg_get_constraintdef and friends, instead of native wit ... regards, tom lane ---(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] USING INDEX TABLESPACE
Applied. I also added some code to ruleutils.c to make pg_get_constraintdef output the USING INDEX TABLESPACE clause at need. We might want to think about getting pg_dump to rely more on pg_get_constraintdef and friends, instead of native wit ... Yes, that was really dumb of me not to think of that :/ Especially since I wrote the primary key and unique parts of pg_get_constraintdef... :P I would like to have pg_get_xxxdef for everything. Tables, whole databases, etc. :) Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
