Re: [PATCHES] contrib/ sparse code cleanup
Neil, go ahead ! Oleg On Fri, 5 Nov 2004, Neil Conway wrote: [ Oleg, I've CC'd you because this patch makes some modifications, albeit trivial ones, to tsearch2; let me know if you object to me applying it ] This patch makes some cleanups to contrib/ to silence some sparse warnings: - remove pointless "extern" keyword from some function definitions in contrib/tsearch2 - use "NULL" not "0" as NULL pointer in contrib/tsearch, contrib/tsearch2, contrib/pgbench, and contrib/vacuumlo Barring any objections I will apply this tomorrow. -Neil Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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
[PATCHES] contrib/xml2: add function xml_encode_special_chars
Hi,
attached is a patch that adds the function xml_encode_special_chars to
the xml2 contrib module. It's against 8.0beta4. It's intended for
commit.
I would have CC'ed the author, John Gray, but I was unable to find his
email address.
--
Markus Bertheau <[EMAIL PROTECTED]>
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/: config.log
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/: config.status
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/contrib/xml2: libpgxml.a
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/contrib/xml2: libpgxml.so
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/contrib/xml2: libpgxml.so.0
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/contrib/xml2: libpgxml.so.0.0
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/contrib/xml2: pgxml.sql
diff -cr postgresql-8.0.0beta4.orig/contrib/xml2/pgxml.sql.in postgresql-8.0.0beta4/contrib/xml2/pgxml.sql.in
*** postgresql-8.0.0beta4.orig/contrib/xml2/pgxml.sql.in 2004-03-07 21:41:27.0 +0100
--- postgresql-8.0.0beta4/contrib/xml2/pgxml.sql.in 2004-11-05 12:20:42.608943509 +0100
***
*** 3,8
--- 3,11
CREATE OR REPLACE FUNCTION xml_valid(text) RETURNS bool
AS 'MODULE_PATHNAME' LANGUAGE 'c' WITH (isStrict);
+ CREATE OR REPLACE FUNCTION xml_encode_special_chars(text) RETURNS text
+ AS 'MODULE_PATHNAME' LANGUAGE 'c' WITH (isStrict);
+
CREATE OR REPLACE FUNCTION xpath_string(text,text) RETURNS text
AS 'MODULE_PATHNAME' LANGUAGE 'c' WITH (isStrict);
diff -cr postgresql-8.0.0beta4.orig/contrib/xml2/xpath.c postgresql-8.0.0beta4/contrib/xml2/xpath.c
*** postgresql-8.0.0beta4.orig/contrib/xml2/xpath.c 2004-10-13 03:26:42.0 +0200
--- postgresql-8.0.0beta4/contrib/xml2/xpath.c 2004-11-05 12:20:13.131025200 +0100
***
*** 40,45
--- 40,46
Datum xml_valid(PG_FUNCTION_ARGS);
+ Datum xml_encode_special_chars(PG_FUNCTION_ARGS);
Datum xpath_nodeset(PG_FUNCTION_ARGS);
Datum xpath_string(PG_FUNCTION_ARGS);
Datum xpath_number(PG_FUNCTION_ARGS);
***
*** 186,191
--- 187,220
}
+ /* Encodes special characters (<, >, &, " and \r) as XML entities */
+
+ PG_FUNCTION_INFO_V1(xml_encode_special_chars);
+
+ Datum
+ xml_encode_special_chars(PG_FUNCTION_ARGS)
+ {
+ text *tin = PG_GETARG_TEXT_P(0);
+ text *tout;
+ int32 ressize;
+ xmlChar *ts, *tt;
+
+ ts = pgxml_texttoxmlchar(tin);
+
+ tt = xmlEncodeSpecialChars(NULL, ts);
+
+ pfree(ts);
+
+ ressize = strlen(tt);
+ tout = (text *) palloc(ressize + VARHDRSZ);
+ memcpy(VARDATA(tout), tt, ressize);
+ VARATT_SIZEP(tout) = ressize + VARHDRSZ;
+
+ xmlFree(tt);
+
+ PG_RETURN_TEXT_P(tout);
+ }
+
static xmlChar
*
pgxmlNodeSetToText(xmlNodeSetPtr nodeset,
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/contrib/xml2: xpath.o
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/contrib/xml2: xslt_proc.o
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/: GNUmakefile
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/backend/port: dynloader.c
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/backend/port: pg_sema.c
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/backend/port: pg_shmem.c
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/backend/port: tas.s
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/include: dynloader.h
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/include: pg_config.h
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/include: pg_config_os.h
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src/include: stamp-h
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src: Makefile.global
ÐÐÐÑÐÐ Ð postgresql-8.0.0beta4/src: Makefile.port
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
The intuitive understanding of a file is certainly something like "a file called 'baz.c' residing at 'foo/bar/', which contains the BAZ subsystem". Now, when renaming/moving a file such an intuitive understanding is partially lost. UI-wise that's a problem which I haven't ever seen solved well. However, other SCM systems such as Subversion and Continuus (and our to-be-released system Maint, and certainly others) treat files as unique entities unrelated to their path, and thus don't have problems with moves. With regards to modes of working this, it boils down to two methods. One is treating directories as first class entities (opposed to CVS which treats dirs as semi-relevant appendices to real files), versioned to contain a list of children, or simpler yet, to store the parent directory as an meaningful attribute of an object. Both methods have their pros and cons, the latter is somehow simpler to intuitively grasp for people. This doesn't really answer the question of what tool Postgres might change to, but it seems that Subversion is a good tool one should consider. And by golly, CVS is bad. Just consider the cons – having to forbid renames in all but the most necessary cases – it just invites cruft into any project. d. -- David Helgason, Business Development et al., Over the Edge I/S (http://otee.dk) Direct line +45 2620 0663 Main line +45 3264 5049 On 4. nov 2004, at 20:41, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. AFAICS the only nondestructive way to do this is to cvs delete and cvs add, with a commit comment saying where the files were moved from. Then when you are looking at them in CVS, you'd have to navigate over to the previous location (by hand, probably; the commit comment isn't going to automate this for you) and look in the Attic to read the prior CVS history. It's not impossible, certainly, but it discourages moving files for less than the very best of reasons. (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] CVS should die
Joerg Hessdoerfer wrote: Yes, some do. At least SVN (Subversion) can handle moves very well, and especially it doesn't loose history on moves/renames. SVN holds it's repo entries in a database like 'filesystem', which can be backed by BDB4 or flat files (as of 1.1). SVN has proven to be stable in many OSS projects, and vastly superior over CVS especially in handling multi-GB projects containing binary files in our company. I refrain from listing all the advantages, if interested, have a look for yourself at http://subversion.tigris.org Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. PostreSQL must be the absolute best choice for that, right? So knowledge of SVN and some future collaboration could perhaps be beneficial for both parties. SVN is also targeted as a CVS replacement and a CVS user will feel very much at home. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] CVS should die
Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a "compelling reason" to use a particular version control system as I can imagine. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] GiST: memory allocation, cleanup
Neil Conway <[EMAIL PROTECTED]> writes: > Attached is a patch that makes some cleanups and improvements to GiST, > as well as a few semi-related cleanups. Changes: > ... > QUESTION: given a ScanKey for an index scan, GiST overwrites the > ScanKey's sk_func to point to the user-defined Consistent method > (gistrescan() in gistscan.c). When doing a GiST index scan we can ensure > that the sk_func is invoked in a short-lived memory context > (gistfindnext() in gistget.c). Is it safe to assume that anywhere else > in the backend that invokes the ScanKey's sk_func, it is done in a > short-lived memory context? I think you can assume that noplace else in the backend will invoke the sk_func, period. If it did, it'd be passing the wrong parameters --- the Consistent method doesn't take the same args as a plain indexable operator would. > - mark the array that indicates NULLs that is passed to > index_formtuple() as 'const', and fix the resulting fallout I'm a bit dubious about this, mainly because you did not likewise const-ify the other input arguments; it seems confusing to do a partial const-ification. > - after doing an index build, there was previously a long comment and a > few lines of code that used the # of index tuples and heap tuples > (computed by the index build) to update the optimizer's statistics. This > code was duplicated 4 times (once for each type of index); I added a > function called IndexUpdateStats() in catalog/index.c and changed each > index's build function to call that function. The only thing I don't like about this is that it's not apparent that the function would close the heap & index relations, so the calling code will now look like it's leaking the relation references. Maybe call it IndexCloseAndUpdateStats or something like that? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] GiST: memory allocation, cleanup
On Fri, Nov 05, 2004 at 04:41:00PM +1100, Neil Conway wrote: > Comments welcome. I would like to apply this to 8.1 at some point after > we branch for 8.0. I thought I would post this patch to get some > feedback before starting on further GiST work (speculatively, adding > support for concurrency and making it WAL-safe). What are you going to base your concurrency work on? I wonder because I skimmed through Marcel Kornacker's theses, and for example it mentioned use of predicate locking (among other interesting things). Do you have any ideas yet on how to handle that? -- Alvaro Herrera () Oh, oh, las chicas galacianas, lo harán por las perlas, ¡Y las de Arrakis por el agua! Pero si buscas damas Que se consuman como llamas, ¡Prueba una hija de Caladan! (Gurney Halleck) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] GiST: memory allocation, cleanup
Alvaro Herrera wrote: What are you going to base your concurrency work on? I wonder because I skimmed through Marcel Kornacker's theses, and for example it mentioned use of predicate locking (among other interesting things). Do you have any ideas yet on how to handle that? I've read a paper[1] on concurrency and recovery by Kornacker, C. Mohan and Hellerstein, which is presumably pretty close to Kornacker's thesis work (which I'll definitely read later). My understanding is that there's no need to implement predicate locking for GiST any more than for B+-trees -- it's a nice feature to prevent phantoms, but not a requirement for implementing page-level concurrency. So I haven't given any thought to implementing it. If I've misunderstood, please let me know. -Neil [1] http://db.cs.berkeley.edu/papers/sigmod97-gist.pdf ---(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] contrib/xml2: add function xml_encode_special_chars
Ð ÐÐÑ, 06.11.2004, Ð 01:24, Peter Eisentraut ÐÐÑÐÑ: > Markus Bertheau wrote: > > attached is a patch that adds the function xml_encode_special_chars > > to the xml2 contrib module. It's against 8.0beta4. It's intended for > > commit. > > Would you also tell us what this function does? It calls the similarly named function from libxml2. It replaces characters that carry a special meaning in XML (<, >, &, " and \r) with their respective XML entities. -- Markus Bertheau <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] contrib/xml2: add function xml_encode_special_chars
Markus Bertheau wrote: > attached is a patch that adds the function xml_encode_special_chars > to the xml2 contrib module. It's against 8.0beta4. It's intended for > commit. Would you also tell us what this function does? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[PATCHES] yet another .exe path fix
The "adjustments" made to my previous patch to remove a trailing .exe
from get_progname()'s result broke it. The attached patch, which I have
tested, fixes the breakage.
cheers
andrew
Index: src/port/path.c
===
RCS file: /home/cvsmirror/pgsql/src/port/path.c,v
retrieving revision 1.42
diff -c -r1.42 path.c
*** src/port/path.c 6 Nov 2004 01:16:22 - 1.42
--- src/port/path.c 6 Nov 2004 03:34:56 -
***
*** 285,291
#if defined(__CYGWIN__) || defined(WIN32)
/* strip .exe suffix, regardless of case */
if (strlen(nodir_name) > sizeof(EXE) - 1 &&
! pg_strcasecmp(nodir_name + strlen(nodir_name)-sizeof(EXE)-1, EXE) == 0)
{
char *progname;
--- 285,291
#if defined(__CYGWIN__) || defined(WIN32)
/* strip .exe suffix, regardless of case */
if (strlen(nodir_name) > sizeof(EXE) - 1 &&
! pg_strcasecmp(nodir_name + strlen(nodir_name)-(sizeof(EXE)-1), EXE) == 0)
{
char *progname;
***
*** 295,301
fprintf(stderr, "%s: out of memory\n", nodir_name);
exit(1); /* This could exit the postmaster */
}
! progname[strlen(progname) - sizeof(EXE) - 1] = '\0';
nodir_name = progname;
}
#endif
--- 295,301
fprintf(stderr, "%s: out of memory\n", nodir_name);
exit(1); /* This could exit the postmaster */
}
! progname[strlen(progname) - (sizeof(EXE) - 1)] = '\0';
nodir_name = progname;
}
#endif
---(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] yet another .exe path fix
Andrew Dunstan <[EMAIL PROTECTED]> writes: > The "adjustments" made to my previous patch to remove a trailing .exe > from get_progname()'s result broke it. The attached patch, which I have > tested, fixes the breakage. Applied. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] psql \! WIN32 cleanup
The attached applied patch tests for COMSPEC in the right place and
supplies a reasonable shell default on Win32.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.130
diff -c -c -r1.130 command.c
*** src/bin/psql/command.c 4 Nov 2004 22:25:14 - 1.130
--- src/bin/psql/command.c 6 Nov 2004 04:18:05 -
***
*** 1525,1531
--- 1525,1535
+ #ifndef WIN32
#define DEFAULT_SHELL "/bin/sh"
+ #else
+ #define DEFAULT_SHELL "c:/windows/system32/cmd.exe"
+ #endif
static bool
do_shell(const char *command)
***
*** 1537,1547
char *sys;
const char *shellName = NULL;
#ifdef WIN32
- shellName = getenv("COMSPEC");
- #endif
if (shellName == NULL)
! shellName = getenv("SHELL");
if (shellName == NULL)
shellName = DEFAULT_SHELL;
--- 1541,1551
char *sys;
const char *shellName = NULL;
+ shellName = getenv("SHELL");
#ifdef WIN32
if (shellName == NULL)
! shellName = getenv("COMSPEC");
! #endif
if (shellName == NULL)
shellName = DEFAULT_SHELL;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[PATCHES] ON COMMIT and foreign keys
Hackers,
There's a bug with temporary tables signalled ON COMMIT DELETE ROWS,
when they contain foreign key references. An example:
alvherre=# begin;
BEGIN
alvherre=# CREATE TEMP TABLE foo (a int PRIMARY KEY) ON COMMIT DELETE ROWS;
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table
"foo"
CREATE TABLE
alvherre=# CREATE TEMP TABLE bar (a int REFERENCES foo) ON COMMIT DELETE ROWS;
CREATE TABLE
alvherre=# COMMIT;
ERROR: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "bar" references "foo" via foreign key constraint "bar_a_fkey".
Say again? Certainly this shouldn't happen, because both tables are
supposed to lose rows on transaction commit. But this isn't working.
The attached patch fixes this bug. (In all likelyhood, not a lot of
people uses referential integrity on temp tables, and that's why this
hasn't been reported. But it's a bug anyway.)
Incidentally ("collateral damage"), the patch modifies the TRUNCATE
command so that it can work on multiple tables. In particular, if
foreign key references are all internal to the group that's being
truncated, the command is allowed.
There's one thing that bothers me on this patch: the fact that
pg_constraint has to be scanned multiple times, and they are all
seqscans. Not sure what to do about that. Maybe there's a way to do
better?
Also, observe that when the TRUNCATE operation is aborted because of a
foreign key, a HINT is emitted as well telling the user to truncate the
referencing table too. This is IMHO a good hint, but it may be
misleading when the truncation has taken the ON COMMIT DELETE ROWS path.
Not sure if it's worth fixing (maybe the hint should suggest to add ON
COMMIT DELETE ROWS to the referencing table as well?).
Please have a look. The patch is not as intrusive as it looks; there's
a lot of whitespace change.
--
Alvaro Herrera ()
"Ellos andaban todos desnudos como su madre los parió, y también las mujeres,
aunque no vi más que una, harto moza, y todos los que yo vi eran todos
mancebos, que ninguno vi de edad de más de XXX años" (Cristóbal Colón)
Index: doc/src/sgml/ref/truncate.sgml
===
RCS file: /home/alvherre/cvs/pgsql/doc/src/sgml/ref/truncate.sgml,v
retrieving revision 1.17
diff -c -r1.17 truncate.sgml
*** doc/src/sgml/ref/truncate.sgml 23 Mar 2004 13:21:41 - 1.17
--- doc/src/sgml/ref/truncate.sgml 6 Nov 2004 01:20:19 -
***
*** 11,17
TRUNCATE
! empty a table
--- 11,17
TRUNCATE
! empty a set of tables
***
*** 20,26
! TRUNCATE [ TABLE ] name
--- 20,26
! TRUNCATE [ TABLE ] name [, ...]
***
*** 28,37
Description
!TRUNCATE quickly removes all rows from a
!table. It has the same effect as an unqualified
!DELETE but since it does not actually scan the
!table it is faster. This is most useful on large tables.
--- 28,37
Description
!TRUNCATE quickly removes all rows from a set of
!tables. It has the same effect as an unqualified
!DELETE on each of them, but since it does not actually
!scan the tables it is faster. This is most useful on large tables.
***
*** 55,67
TRUNCATE cannot be used if there are foreign-key references
!to the table from other tables. Checking validity in such cases would
!require table scans, and the whole point is not to do one.
TRUNCATE will not run any user-defined ON
!DELETE triggers that might exist for the table.
--- 55,68
TRUNCATE cannot be used if there are foreign-key references
!to the table from other tables, unless all such tables are also truncated
!in the same command. Checking validity in such cases would require table
!scans, and the whole point is not to do one.
TRUNCATE will not run any user-defined ON
!DELETE triggers that might exist for the tables.
***
*** 69,78
Examples
!Truncate the table bigtable:
! TRUNCATE TABLE bigtable;
--- 70,79
Examples
!Truncate the tables bigtable and fattable:
! TRUNCATE TABLE bigtable, fattable;
Index: src/backend/catalog/heap.c
===
RCS file: /home/alvherre/cvs/pgsql/src/backend/catalog/heap.c,v
retrieving revision 1.276
diff -c -r1.276 heap.c
*** src/backend/catalog/heap.c 31 Aug 2004 17:10:36 - 1.276
--- src/backend/catalog/heap.c 6 Nov 2004 03:23:44 -
***
*** 2002,2102
/*
* heap_truncate
*
! * This routine deletes all data within the specified relation.
*
* This is not transaction-safe! There is another, transaction-safe
* implementa
Re: [PATCHES] ON COMMIT and foreign keys
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Incidentally ("collateral damage"), the patch modifies the TRUNCATE
> command so that it can work on multiple tables. In particular, if
> foreign key references are all internal to the group that's being
> truncated, the command is allowed.
I think this is a feature addition that you've cleverly managed to
present as a bug fix ;-). While I like the feature, I've got very
mixed emotions about applying it this late in beta. The "bug" exists
in 7.4 but has yet to be reported in the field, which says to me that
we could leave it unfixed in 8.0 as well. Conservatism would suggest
holding the change for 8.1. OTOH, multiple TRUNCATE would be a useful
feature --- it came up just the other day.
Comments anyone?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] psql \! WIN32 cleanup
Bruce Momjian <[EMAIL PROTECTED]> writes: > The attached applied patch tests for COMSPEC in the right place and > supplies a reasonable shell default on Win32. > + #define DEFAULT_SHELL "c:/windows/system32/cmd.exe" Is it really a good idea to assume that the Windows installation is on drive C: ? (This is an honest question, not a rhetorical one. I dunno whether inserting the C: is better than leaving it off. I can think of cases where either way will break, but I'm unsure what's most likely in practice.) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] psql \! WIN32 cleanup
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > The attached applied patch tests for COMSPEC in the right place and > > supplies a reasonable shell default on Win32. > > > + #define DEFAULT_SHELL "c:/windows/system32/cmd.exe" > > Is it really a good idea to assume that the Windows installation is on > drive C: ? > > (This is an honest question, not a rhetorical one. I dunno whether > inserting the C: is better than leaving it off. I can think of cases > where either way will break, but I'm unsure what's most likely in > practice.) Not sure. Should we just do "/windows/system32/cmd.exe" and leave off the C:? The previous default was "/bin/sh" and that certainly will not work on Win32. -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] ON COMMIT and foreign keys
Bruce Momjian wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Incidentally ("collateral damage"), the patch modifies the TRUNCATE
> > > command so that it can work on multiple tables. In particular, if
> > > foreign key references are all internal to the group that's being
> > > truncated, the command is allowed.
> >
> > I think this is a feature addition that you've cleverly managed to
> > present as a bug fix ;-). While I like the feature, I've got very
> > mixed emotions about applying it this late in beta. The "bug" exists
> > in 7.4 but has yet to be reported in the field, which says to me that
> > we could leave it unfixed in 8.0 as well. Conservatism would suggest
> > holding the change for 8.1. OTOH, multiple TRUNCATE would be a useful
> > feature --- it came up just the other day.
> >
> > Comments anyone?
>
> Alvaro, would you post the patch skipping whitespace changes. As posted
> the patch does look very large, as you suggested.
I generated the diff myself, attached.
--
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
? config.log
? GNUmakefile
? config.status
? src/Makefile.custom
? src/log
? src/Makefile.global
? src/bin/psql/psql
? src/bin/psql/po/cs.mo
? src/bin/psql/po/de.mo
? src/bin/psql/po/es.mo
? src/bin/psql/po/fa.mo
? src/bin/psql/po/fr.mo
? src/bin/psql/po/hu.mo
? src/bin/psql/po/it.mo
? src/bin/psql/po/nb.mo
? src/bin/psql/po/pt_BR.mo
? src/bin/psql/po/ru.mo
? src/bin/psql/po/sk.mo
? src/bin/psql/po/sl.mo
? src/bin/psql/po/sv.mo
? src/bin/psql/po/tr.mo
? src/bin/psql/po/zh_CN.mo
? src/bin/psql/po/zh_TW.mo
? src/include/pg_config.h
? src/include/stamp-h
? src/interfaces/libpq/libpq.so.3.2
? src/interfaces/libpq/po/af.mo
? src/interfaces/libpq/po/cs.mo
? src/interfaces/libpq/po/de.mo
? src/interfaces/libpq/po/es.mo
? src/interfaces/libpq/po/fr.mo
? src/interfaces/libpq/po/hr.mo
? src/interfaces/libpq/po/it.mo
? src/interfaces/libpq/po/nb.mo
? src/interfaces/libpq/po/pt_BR.mo
? src/interfaces/libpq/po/ru.mo
? src/interfaces/libpq/po/sk.mo
? src/interfaces/libpq/po/sl.mo
? src/interfaces/libpq/po/sv.mo
? src/interfaces/libpq/po/tr.mo
? src/interfaces/libpq/po/zh_CN.mo
? src/interfaces/libpq/po/zh_TW.mo
? src/port/pg_config_paths.h
Index: doc/src/sgml/ref/truncate.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/truncate.sgml,v
retrieving revision 1.17
diff -c -c -b -r1.17 truncate.sgml
*** doc/src/sgml/ref/truncate.sgml 23 Mar 2004 13:21:41 - 1.17
--- doc/src/sgml/ref/truncate.sgml 6 Nov 2004 05:56:52 -
***
*** 11,17
TRUNCATE
! empty a table
--- 11,17
TRUNCATE
! empty a set of tables
***
*** 20,26
! TRUNCATE [ TABLE ] name
--- 20,26
! TRUNCATE [ TABLE ] name [, ...]
***
*** 28,37
Description
!TRUNCATE quickly removes all rows from a
!table. It has the same effect as an unqualified
!DELETE but since it does not actually scan the
!table it is faster. This is most useful on large tables.
--- 28,37
Description
!TRUNCATE quickly removes all rows from a set of
!tables. It has the same effect as an unqualified
!DELETE on each of them, but since it does not actually
!scan the tables it is faster. This is most useful on large tables.
***
*** 55,67
TRUNCATE cannot be used if there are foreign-key references
!to the table from other tables. Checking validity in such cases would
!require table scans, and the whole point is not to do one.
TRUNCATE will not run any user-defined ON
!DELETE triggers that might exist for the table.
--- 55,68
TRUNCATE cannot be used if there are foreign-key references
!to the table from other tables, unless all such tables are also truncated
!in the same command. Checking validity in such cases would require table
!scans, and the whole point is not to do one.
TRUNCATE will not run any user-defined ON
!DELETE triggers that might exist for the tables.
***
*** 69,78
Examples
!Truncate the table bigtable:
! TRUNCATE TABLE bigtable;
--- 70,79
Examples
!Truncate the tables bigtable and fattable:
! TRUNCATE TABLE bigtable, fattable;
Index: src/backend/catalog/heap.c
===
RCS file: /cvsroot/pgsql/src/backend/catalog/heap.c,v
retrieving revision 1.276
diff -c -c -b -r1.276 heap.c
*** src/backend/catalog/heap.c 31 Aug 2004 17:10:36
Re: [PATCHES] ON COMMIT and foreign keys
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Incidentally ("collateral damage"), the patch modifies the TRUNCATE
> > command so that it can work on multiple tables. In particular, if
> > foreign key references are all internal to the group that's being
> > truncated, the command is allowed.
>
> I think this is a feature addition that you've cleverly managed to
> present as a bug fix ;-). While I like the feature, I've got very
> mixed emotions about applying it this late in beta. The "bug" exists
> in 7.4 but has yet to be reported in the field, which says to me that
> we could leave it unfixed in 8.0 as well. Conservatism would suggest
> holding the change for 8.1. OTOH, multiple TRUNCATE would be a useful
> feature --- it came up just the other day.
>
> Comments anyone?
Alvaro, would you post the patch skipping whitespace changes. As posted
the patch does look very large, as you suggested.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
