Re: [PATCHES] Configurable Penalty Costs for Levenshtein
On Thu, 03 Apr 2008, Tom Lane <[EMAIL PROTECTED]> writes: > Volkan YAZICI <[EMAIL PROTECTED]> writes: >> Sorry for the delay, but the reply of Tom didn't reach me. I've modified >> the patch according to Tom's comments. I hope I am not too late. > > Applied after considerable revision. This patch: > > * introduced a memory stomp that was not there before (I strongly > recommend testing C code in an --enable-cassert build) > * added a user-visible feature without documenting it > * undid a conflicting patch that had been applied since your first version > * removed a number of useful comments from the code > > I cleaned it up and applied anyway, but generally we expect a higher > quality standard for patches that are claimed to be ready to apply. Thanks so much for your kindness. Please don't hesistate to reject the patch next time by dropping me an email with the above lines mentioning about your considerations, and I'll happily fix it at my best and resend it. I don't want to interrupt your work with such trivial stuff. Regards. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Configurable Penalty Costs for Levenshtein
Hi, Sorry for the delay, but the reply of Tom didn't reach me. I've modified the patch according to Tom's comments. I hope I am not too late. Regards. fuzzystrmatch-levenshtein.patch.1 Description: Binary data On Wed, 2 Apr 2008, Bruce Momjian <[EMAIL PROTECTED]> writes: > Because of lack of reply from the author, this has been saved for the > next commit-fest: > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold > > ------- > > Tom Lane wrote: >> Volkan YAZICI <[EMAIL PROTECTED]> writes: >> > I noticed a small typo in the patch. >> > prev = palloc((m + n) * sizeof(char)); >> > line should look like >> > prev = palloc(2 * m * sizeof(char)); >> > instead. >> >> If that's wrong, aren't the comments and the length restriction limit >> also wrong? -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] stored procedure stats in collector
Hi, On Sun, 23 Mar 2008, Martin Pihlak <[EMAIL PROTECTED]> writes: > Attached is a patch that enables tracking function calls through > the stats subsystem. Original discussion: > http://archives.postgresql.org/pgsql-hackers/2007-07/msg00377.php > > Introduces new guc variable - track_functions. Possible values are: > none - no collection, default > pl - tracks procedural language functions > all - tracks procedural, SQL and C (not internal) functions I might have missed the discussion, but I'd love to see a more flexible interface for configuration parameters. For instance, it'd be great if we can specify which procedural languages to track in the `pl' GUC. Moreover, if it'd be possible to specify which specific functions we want to try, then that would be awesome as well. For instance, possible configuration combinations for track_functions can be: `pl:*'- Tracks procedural, SQL and C (not internal) functions in the `public' schema. `pl:pgsql'- Tracks only PL/pgSQL functions. `pl:scheme' - Tracks only PL/scheme functions. `foo(int, int)' - Tracks related `foo' function in the public schema. `stock.foo(int, int)' - Tracks related `foo' function in the `stock' schema. `pl:stock.*' - Tracks procedural, SQL and C (not internal) functions in the `stock' schema. Syntax can obviously be much more consistent. (These are just what I come up with for the very moment.) And I'm aware of the overhead and complexity(?) this sort of scheme will bring, but I really want to use such a useful feature with mentioned flexibilities. Regards. - Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Configurable Penalty Costs for Levenshtein
Hi, I noticed a small typo in the patch. prev = palloc((m + n) * sizeof(char)); line should look like prev = palloc(2 * m * sizeof(char)); instead. Regards. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Configurable Penalty Costs for Levenshtein
Volkan YAZICI <[EMAIL PROTECTED]> writes: > Following patch implements configurable penalty costs for levenshtein > distance metric in fuzzystrmatch contrib module. Is there a problem with the patch? Would anybody mind helping me to figure out the reason of this lack of interest, after 15 days. Regards. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Configurable Penalty Costs for Levenshtein
Hi, Following patch implements configurable penalty costs for levenshtein distance metric in fuzzystrmatch contrib module. It doesn't introduce any compatibility issues. Just implements levenshtein(text,text,int,int,int) function on top of fuzzystrmatch.c:levenshtein_internal(). At the same time, levenshtein(text,text) becomes just a wrapper for levenshtein(text,text,1,1,1) call. BTW, in current CVS tip if (cols/rows == 0) ... checks in fuzzyztrmatch.c:levenshtein() never fail because of cols/rows = strlen(...) + 1; FYI. Regards. ? contrib/fuzzystrmatch/fuzzystrmatch.sql ? contrib/fuzzystrmatch/libfuzzystrmatch.so.0.0 Index: contrib/fuzzystrmatch/README.fuzzystrmatch === RCS file: /projects/cvsroot/pgsql/contrib/fuzzystrmatch/README.fuzzystrmatch,v retrieving revision 1.10 diff -c -r1.10 README.fuzzystrmatch *** contrib/fuzzystrmatch/README.fuzzystrmatch 5 Jan 2007 22:19:17 - 1.10 --- contrib/fuzzystrmatch/README.fuzzystrmatch 17 Oct 2007 13:58:09 - *** *** 14,19 --- 14,20 * found at http://www.merriampark.com/ld.htm * Also looked at levenshtein.c in the PHP 4.0.6 distribution for * inspiration. + * Configurable penalty costs extension is introduced by Volkan YAZICI. * * metaphone() * --- *** *** 116,121 --- 117,158 == Name + levenshtein -- calculates levenshtein distance with respect +to specified costs. + + Synopsis + + levenshtein(text source, text target, + int insert_cost, int delete_cost, int substitution_cost) + + Inputs + + source + any text string, 255 characters max, NOT NULL + + target + any text string, 255 characters max, NOT NULL + + insert_cost + cost of extra inserted characters + + delete_cost + cost of missing characters + + substitution_cost + cost of character substitutions + + Outputs + + Returns int + + Example usage + + select levenshtein('GUMBO','GAMBOL', 1, 1, 3); + + == + Name + metaphone -- calculates the metaphone code of an input string Synopsis *** *** 140,144 select metaphone('GUMBO',4); == ! -- Joe Conway ! --- 177,180 select metaphone('GUMBO',4); == ! -- Joe Conway \ No newline at end of file Index: contrib/fuzzystrmatch/fuzzystrmatch.c === RCS file: /projects/cvsroot/pgsql/contrib/fuzzystrmatch/fuzzystrmatch.c,v retrieving revision 1.24 diff -c -r1.24 fuzzystrmatch.c *** contrib/fuzzystrmatch/fuzzystrmatch.c 13 Feb 2007 18:00:35 - 1.24 --- contrib/fuzzystrmatch/fuzzystrmatch.c 17 Oct 2007 13:58:09 - *** *** 15,20 --- 15,21 * found at http://www.merriampark.com/ld.htm * Also looked at levenshtein.c in the PHP 4.0.6 distribution for * inspiration. + * Configurable penalty consts extension is introduced by Volkan YAZICI. * * metaphone() * --- *** *** 47,201 PG_MODULE_MAGIC; /* ! * Calculates Levenshtein Distance between two strings. ! * Uses simplest and fastest cost model only, i.e. assumes a cost of 1 for ! * each deletion, substitution, or insertion. */ ! PG_FUNCTION_INFO_V1(levenshtein); ! Datum ! levenshtein(PG_FUNCTION_ARGS) { ! char *str_s; ! char *str_s0; ! char *str_t; ! int cols = 0; ! int rows = 0; ! int *u_cells; ! int *l_cells; ! int *tmp; ! int i; ! int j; ! ! /* ! * Fetch the arguments. str_s is referred to as the "source" cols = length ! * of source + 1 to allow for the initialization column str_t is referred ! * to as the "target", rows = length of target + 1 rows = length of target ! * + 1 to allow for the initialization row ! */ ! str_s = DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(PG_GETARG_TEXT_P(0; ! str_t = DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(PG_GETARG_TEXT_P(1; ! ! cols = strlen(str_s) + 1; ! rows = strlen(str_t) + 1; /* ! * Restrict the length of the strings being compared to something ! * reasonable because we will have to perform rows * cols calculations. If ! * longer strings need to be compared, increase MAX_LEVENSHTEIN_STRLEN to ! * suit (but within your tolerance for speed and memory usage). */ ! if ((cols > MAX_LEVENSHTEIN_STRLEN + 1) || (rows > MAX_LEVENSHTEIN_STRLEN + 1)) ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), errmsg("argument exceeds the maximum length of %d bytes", MAX_LEVENSHTEIN_STRLEN))); !
Re: [PATCHES] psql patch: new host/port without leaving session
On Apr 02 12:37, Tom Lane wrote: > Volkan YAZICI <[EMAIL PROTECTED]> writes: > > Won't it be better if we distinguish between "default" and "current" > > value of a parameter with '-' (for the "current") and '+' (for the > > "default") characters? For example: > > That seems like a frammish without sufficient use-case. You can always > quit and restart psql to get back to the defaults. You can always quit and restart psql with new connection parameters. In this situation, we shouldn't bother with \c too. Don't they share the same use-case? (If there's any.) Regards. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql patch: new host/port without leaving session
On Apr 01 07:07, Neil Conway wrote: > One question about behavior: in the attached patch, omitting an argument > to \connect or specifying "-" are treated equivalently -- the value for > that parameter from the previous connection is used, otherwise NULL (for > the libpq default). Is this what people want? (One possible complaint is > that once you specify a parameter, you can't get back to the libpq > default without specifying it explicitly.) Won't it be better if we distinguish between "default" and "current" value of a parameter with '-' (for the "current") and '+' (for the "default") characters? For example: \c + - hst Connect to "default" database with "current" user on host hst. (Omitted values can be treated as "current".) \c + + hst - Connect to "default" database with "default" user on host hst on "current" port. So we'll still have chance to get back to the libpq defaults. Regards. ---(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 patch: new host/port without leaving session
Hi, I've written do_connect() and \c handling part from scratch in the attached patch. Here are some features introduced: - \c syntax is extended. (See comment lines just above \c stuff.) - do_connect() AI (like used for prompting password or informing client about connect attempt's result.) improved. - Some code clean up. If you'd agree with the style, I'll add patch for the documentation and PO files too. Regards. P.S. Patch passed regressions tests on CVS tip. On Dec 13 04:29, David Fetter wrote: > Please find enclosed a patch that lets you use \c to connect > (optionally) to a new host and port without exiting psql. This > eliminates, IMHO, a surprise in that you can now connect to PostgreSQL > on a differnt machine from the one where you started your session. > This should help people who use psql as an administrative tool. Index: src/bin/psql/command.c === RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v retrieving revision 1.164 diff -c -r1.164 command.c *** src/bin/psql/command.c 5 Mar 2006 15:58:51 - 1.164 --- src/bin/psql/command.c 12 Mar 2006 17:42:10 - *** *** 188,215 free(opt); } ! /*-- !* \c or \connect -- connect to new database or as different user, !* and/or new host and/or port * !* \c foo bar [-] [-]connect to db "foo" as user "bar" on current host and port !* \c foo [-] [-] [-] connect to db "foo" as current user on current host and port !* \c - bar [-] [-] connect to current db as user "bar" on current host and port !* \c - - host.domain.tld [-] connect to default db as default user on host.domain.tld on default port !* \c - - - connect to default db as default user on default host at port !* \c connect to default db as default user !*-- */ else if (strcmp(cmd, "c") == 0 || strcmp(cmd, "connect") == 0) { ! char *opt1, ! *opt2, ! *opt3, ! *opt4; ! charopt1q, ! opt2q, ! opt3q, ! opt4q; /* * Ideally we should treat the arguments as SQL identifiers. But for --- 188,221 free(opt); } ! /* !* \c or \connect -- connect to database with using specified parameters. !* !* \c dbname user host port !* !* Place a `-' instead of the related parameter to make it use its current !* value. (If there doesn't exist any current value for the specified !* parameter, it won't get included in the connection string.) * !* Here are some examples: !* !* \c - - hst Connect to current database on current port of !* host "hst" as current user. !* \c - usr - prt Connect to current database on "prt" port of current !* host as user "usr". !* \c dbs Connect to "dbs" database on current port of current !* host as current user. */ else if (strcmp(cmd, "c") == 0 || strcmp(cmd, "connect") == 0) { ! char*opt1, ! *opt2, ! *opt3, ! *opt4; ! char opt1q, !opt2q, !opt3q, !opt4q; /* * Ideally we should treat the arguments as SQL identifiers. But for *** *** 220,272 * double-quote all mixed-case \connect arguments, and then we can get * rid of OT_SQLIDHACK. */ ! opt1 = psql_scan_slash_option(scan_state, ! OT_SQLIDHACK, &opt1q, true); ! opt2 = psql_scan_slash_option(scan_state, ! OT_SQLIDHACK, &opt2q, true); ! opt3 = psql_scan_slash_option(scan_state, ! OT_SQLIDHACK, &opt3q, true); ! opt4 = psql_scan_slash_option(scan_state, ! OT_SQLIDHACK, &opt4q, true); ! ! if (opt4) ! /* gave port */ ! success = do_connect(!opt1q && (strcmp(opt1, "-
Re: [PATCHES] tuple count and v3 functions in psql for COPY
On Feb 11 11:24, Bruce Momjian wrote: > I have updated the patch to match CVS (attached), but am seeing the > following regression differences where the COPY error messages are now > missing. I've revised the patch (attached) and now it seems to be ok - passes regression tests too. Any other comments are welcome. Regards. Index: src/backend/commands/copy.c === RCS file: /projects/cvsroot/pgsql/src/backend/commands/copy.c,v retrieving revision 1.258 diff -c -r1.258 copy.c *** src/backend/commands/copy.c 3 Feb 2006 12:41:07 - 1.258 --- src/backend/commands/copy.c 1 Mar 2006 21:46:28 - *** *** 102,107 --- 102,108 int client_encoding;/* remote side's character encoding */ boolneed_transcoding; /* client encoding diff from server? */ boolencoding_embeds_ascii; /* ASCII can be non-first byte? */ + uint64 processed; /* # of tuples processed */ /* parameters from the COPY command */ Relationrel;/* relation to copy to or from */ *** *** 710,716 * Do not allow the copy if user doesn't have proper permission to access * the table. */ ! void DoCopy(const CopyStmt *stmt) { CopyState cstate; --- 711,717 * Do not allow the copy if user doesn't have proper permission to access * the table. */ ! uint64 DoCopy(const CopyStmt *stmt) { CopyState cstate; *** *** 724,729 --- 725,731 AclMode required_access = (is_from ? ACL_INSERT : ACL_SELECT); AclResult aclresult; ListCell *option; + uint64 processed; /* Allocate workspace and zero all fields */ cstate = (CopyStateData *) palloc0(sizeof(CopyStateData)); *** *** 1019,1024 --- 1021,1027 cstate->line_buf_converted = false; cstate->raw_buf = (char *) palloc(RAW_BUF_SIZE + 1); cstate->raw_buf_index = cstate->raw_buf_len = 0; + cstate->processed = 0; /* Set up encoding conversion info */ cstate->client_encoding = pg_get_client_encoding(); *** *** 1164,1170 --- 1167,1176 pfree(cstate->attribute_buf.data); pfree(cstate->line_buf.data); pfree(cstate->raw_buf); + + processed = cstate->processed; pfree(cstate); + return processed; } *** *** 1399,1404 --- 1405,1412 } CopySendEndOfRow(cstate); + + cstate->processed++; MemoryContextSwitchTo(oldcontext); } *** *** 2002,2007 --- 2010,2017 /* AFTER ROW INSERT Triggers */ ExecARInsertTriggers(estate, resultRelInfo, tuple); + + cstate->processed++; } } Index: src/backend/tcop/utility.c === RCS file: /projects/cvsroot/pgsql/src/backend/tcop/utility.c,v retrieving revision 1.252 diff -c -r1.252 utility.c *** src/backend/tcop/utility.c 12 Feb 2006 19:11:01 - 1.252 --- src/backend/tcop/utility.c 1 Mar 2006 21:46:47 - *** *** 640,646 break; case T_CopyStmt: ! DoCopy((CopyStmt *) parsetree); break; case T_PrepareStmt: --- 640,651 break; case T_CopyStmt: ! { ! uint64 processed = DoCopy((CopyStmt *) parsetree); ! ! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, !"COPY " UINT64_FORMAT, processed); ! } break; case T_PrepareStmt: Index: src/bin/pg_dump/pg_backup_db.c === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_backup_db.c,v retrieving revision 1.69 diff -c -r1.69 pg_backup_db.c *** src/bin/pg_dump/pg_backup_db.c 12 Feb 2006 06:11:50 - 1.69 --- src/bin/pg_dump/pg_backup_db.c 1 Mar 2006 21:46:50 - *** *** 391,396 --- 391,398 * enter COPY mode; this allows us to behave reasonably when trying * to continue after an error in a COPY command. */ + if (AH->pgCopyIn && + PQputCopyData(AH->connection, AH->pgCopyBuf->data, AH->pgCopyBuf->len) < 0) if (AH->pgCopyIn && PQputline(AH->connection, AH->pgCopyBuf->data) != 0) die_horribly(AH, modulename, "error returned by PQputline: %s",
Re: [PATCHES] tuple count and v3 functions in psql for COPY
I've just realized an exception in the sending data while using PQsendCopyData(). Function's blocking behaviour is not guaranteed, therefore a if (PQisnonblocking()) PQsetnonblocking(conn, 0) kind of phrase required before using PQsendCopyData(). But after a small investigation, found that both psql and pg_dump runs in blocking mode - without any PQsetnonblocking() call. Thus, AFAIC, above phrase isn't necessary. FYI. Just wanted to inform. Any comments are welcome. Regards. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] tuple count and v3 functions in psql for COPY
Here's a new try. This one touches to pg_dump side too - for v3 COPY functions usage instead of deprecated ones. I'd be so appreciated if somebody can review attached patch. Regards. Index: src/backend/commands/copy.c === RCS file: /projects/cvsroot/pgsql/src/backend/commands/copy.c,v retrieving revision 1.255 diff -u -c -r1.255 copy.c *** src/backend/commands/copy.c 22 Nov 2005 18:17:08 - 1.255 --- src/backend/commands/copy.c 23 Dec 2005 13:29:57 - *** *** 102,107 --- 102,108 int client_encoding;/* remote side's character encoding */ boolneed_transcoding; /* client encoding diff from server? */ boolclient_only_encoding; /* encoding not valid on server? */ + uint64 processed; /* # of tuples processed */ /* parameters from the COPY command */ Relationrel;/* relation to copy to or from */ *** *** 646,652 * Do not allow the copy if user doesn't have proper permission to access * the table. */ ! void DoCopy(const CopyStmt *stmt) { CopyState cstate; --- 647,653 * Do not allow the copy if user doesn't have proper permission to access * the table. */ ! uint64 DoCopy(const CopyStmt *stmt) { CopyState cstate; *** *** 660,665 --- 661,667 AclMode required_access = (is_from ? ACL_INSERT : ACL_SELECT); AclResult aclresult; ListCell *option; + uint64 processed; /* Allocate workspace and zero all fields */ cstate = (CopyStateData *) palloc0(sizeof(CopyStateData)); *** *** 936,941 --- 938,944 cstate->line_buf_converted = false; cstate->raw_buf = (char *) palloc(RAW_BUF_SIZE + 1); cstate->raw_buf_index = cstate->raw_buf_len = 0; + cstate->processed = 0; /* Set up encoding conversion info */ cstate->client_encoding = pg_get_client_encoding(); *** *** 1080,1086 --- 1083,1092 pfree(cstate->attribute_buf.data); pfree(cstate->line_buf.data); pfree(cstate->raw_buf); + + processed = cstate->processed; pfree(cstate); + return processed; } *** *** 1310,1315 --- 1316,1323 VARSIZE(outputbytes) - VARHDRSZ); } } + + cstate->processed++; } CopySendEndOfRow(cstate); *** *** 1916,1921 --- 1924,1931 /* AFTER ROW INSERT Triggers */ ExecARInsertTriggers(estate, resultRelInfo, tuple); + + cstate->processed++; } } Index: src/backend/tcop/utility.c === RCS file: /projects/cvsroot/pgsql/src/backend/tcop/utility.c,v retrieving revision 1.250 diff -u -c -r1.250 utility.c *** src/backend/tcop/utility.c 29 Nov 2005 01:25:49 - 1.250 --- src/backend/tcop/utility.c 23 Dec 2005 13:29:59 - *** *** 640,646 break; case T_CopyStmt: ! DoCopy((CopyStmt *) parsetree); break; case T_PrepareStmt: --- 640,651 break; case T_CopyStmt: ! { ! uint64 processed = DoCopy((CopyStmt *) parsetree); ! ! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, !"COPY " UINT64_FORMAT, processed); ! } break; case T_PrepareStmt: Index: src/bin/pg_dump/pg_backup_db.c === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_backup_db.c,v retrieving revision 1.66 diff -u -c -r1.66 pg_backup_db.c *** src/bin/pg_dump/pg_backup_db.c 15 Oct 2005 02:49:38 - 1.66 --- src/bin/pg_dump/pg_backup_db.c 23 Dec 2005 13:30:00 - *** *** 389,396 *- */ ! if (PQputline(AH->connection, AH->pgCopyBuf->data) != 0) ! die_horribly(AH, modulename, "error returned by PQputline\n"); resetPQExpBuffer(AH->pgCopyBuf); --- 389,396 *- */ ! if (PQputCopyData(AH->connection, AH->pgCopyBuf->data, AH->pgCopyBuf->len) < 0) ! die_horribly(AH, modulename, "error returned by PQputCopyData\n"); resetPQExpBuffer(AH->pgCopyBuf);
Re: [PATCHES] tuple count and v3 functions in psql for COPY
On Dec 22 01:52, Tom Lane wrote: > > ! { > > ! uint64processed = DoCopy((CopyStmt *) parsetree); > > ! charbuf[21]; > > ! > > ! snprintf(buf, sizeof(buf), UINT64_FORMAT, processed); > > ! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, > > ! "COPY %s", buf); > > ! } > > This is ugly and unnecessary. Why not > > > ! { > > ! uint64processed = DoCopy((CopyStmt *) parsetree); > > ! > > ! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, > > ! "COPY " UINT64_FORMAT, processed); > > ! } At the beginning I used the style as above, but after looking at the source code for INT64_FORMAT usage, saw that nearly all of them use a seperate buffer. Furthermore, in the source code (for instance backend/commands/sequence.c) nearly every buffer size used for INT64_FORMAT is 100. AFAIK, 20+1 is enough for a 64 bit integer. > Also, I think you've broken the psql-side handling of COPY IN. There's > no check for I/O error on the input, and the test for terminator (\.\n) > mistakenly assumes that the terminator could only appear at the start > of the buffer, not to mention assuming that it couldn't span across two > bufferloads. > > The check for \r is wrong too (counterexample: first input line exceeds > 8K), but actually you should just dispense with that entirely, because > if you're going to use PQputCopyEnd then it is not your responsibility > to send the terminator. > > But the *real* problem with this coding is that it will fetch data past > the \., which breaks files that include both COPY data and SQL. Thus > for example this patch breaks pg_dump files. 8K limit is caused by a mis-understanding of me. Thanks so much for the review, I'll try to fix above missing parts ASAP. > ! for (c = p; isdigit((int) *c); ++c) > > Wrong. Use (unsigned char). I found above from "The Open Group Base Specifications Issue 6". I'll fix that too. Regards. -- "We are the middle children of history, raised by television to believe that someday we'll be millionaires and movie stars and rock stars, but we won't. And we're just learning this fact," Tyler said. "So don't fuck with us." ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] tuple count and v3 functions in psql for COPY
I tried to prepare a patch for these TODO items: - Have COPY return the number of rows loaded/unloaded? - Update [pg_dump and] psql to use the new COPY libpq API. Added an "uint64 processed" to "struct CopyStateData". It's incremented each time on a tuple send/receive made by CopyTo/CopyFrom. Collected result is added to COPY command's commandTag which can be gathered by PQcmdStatus(). (Also updated PQcmdTuples() to work with it.) When I tried to modify psql to print the COPY's commandTag, I found that its implementation is really disorganized when we still use old COPY commands. Thus replaced old COPY routines with the new ones. (IMHO, modified design for the psql's COPY should work faster than the previous. Because, in this patch, I don't read input one by one with getc(). Just filled the buffer with fgets and made \r search only in the first and last lines.) Regards. -- "We are the middle children of history, raised by television to believe that someday we'll be millionaires and movie stars and rock stars, but we won't. And we're just learning this fact," Tyler said. "So don't fuck with us." ? src/Makefile.global ? src/cscope.out ? src/backend/cscope.out ? src/backend/postgres ? src/backend/catalog/postgres.bki ? src/backend/catalog/postgres.description ? src/backend/commands/cscope.out ? src/backend/executor/cscope.out ? src/backend/libpq/cscope.out ? src/backend/utils/mb/conversion_procs/conversion_create.sql ? src/backend/utils/mb/conversion_procs/ascii_and_mic/libascii_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/libcyrillic_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/libeuc_cn_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/liblatin2_and_win1250.so.0.0 ? src/backend/utils/mb/conversion_procs/latin_and_mic/liblatin_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/libutf8_and_ascii.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_big5/libutf8_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/libutf8_and_cyrillic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/libutf8_and_euc_cn.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/libutf8_and_euc_jp.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/libutf8_and_euc_kr.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/libutf8_and_euc_tw.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/libutf8_and_gb18030.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/libutf8_and_gbk.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/libutf8_and_iso8859.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/libutf8_and_iso8859_1.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_johab/libutf8_and_johab.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_sjis/libutf8_and_sjis.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_uhc/libutf8_and_uhc.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win1250/libutf8_and_win1250.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win1252/libutf8_and_win1252.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win1256/libutf8_and_win1256.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win1258/libutf8_and_win1258.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_win874/libutf8_and_win874.so.0.0 ? src/bin/initdb/initdb ? src/bin/ipcclean/ipcclean ? src/bin/pg_config/pg_config ? src/bin/pg_controldata/pg_controldata ? src/bin/pg_ctl/pg_ctl ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_dumpall ? src/bin/pg_dump/pg_restore ? src/bin/pg_resetxlog/pg_resetxlog ? src/bin/psql/cscope.out ? src/bin/psql/psql ? src/bin/scripts/clusterdb ? src/bin/scripts/createdb ? src/bin/scripts/createlang ? src/bin/scripts/createuser ? src/bin/scripts/dropdb ? src/bin/scripts/droplang ? src/bin/scripts/dropuser ? src/bin/scripts/reindexdb ? src/bin/scripts/vacuumdb ? src/include/pg_config.h ? src/include/stamp-h ? src/interfaces/ecpg/compatlib/libecpg_compat.so.2.2 ? src/interfaces/ecpg/ecpglib/libecpg.so.5.3 ? src/interfaces/ecpg/pgtypeslib/libpgtypes.so.2.2 ? src/interfaces/ecpg/preproc/ecpg ? src/interfaces/libpq/cscope.out ? src/interfaces/libpq/libpq.so.4.2 ? src/pl/plpgsql/src/libplpgsql.so.1.0 ? src/port/pg_config_paths.h ? src/test/regress/libregress.so.0.0 ? src/test/regress/pg_regress ? src/test/regress/expected/constraints.out ? src/test/regress/expected/copy.out ? src/test/regress/expected/create_function_1.out ? src/test/regress/expected/create_function_2.out ? src/test/regress/expected/misc.out ? src/test/regress/expected/tablespace.out ? src/test/regress/sql/constraints.sql ? src/test/regress/sql/copy.sql
[PATCHES] running script on server shutdown (TODO)
I've written a small patch for following TODO item: «Add GUC variable to run a command on database panic or smart/fast/immediate shutdown.» It adds two GUC variables as: enable_atexit_script_file atexit_script_file postmaster will run related script file with passing shutdown type (like "smart", "fast" or "immediate") as parameter to script file on database shutdown. (Sorry, I'm not so good on PostgreSQL internals, thus couldn't handle "panic" situation at the moment.) I know, it's not the perfect one but I'd be so apprecited to hear suggestions for fixing lost/wrong parts of it. Regards. -- "We are the middle children of history, raised by television to believe that someday we'll be millionaires and movie stars and rock stars, but we won't. And we're just learning this fact," Tyler said. "So don't fuck with us." Index: src/backend/postmaster/postmaster.c === RCS file: /projects/cvsroot/pgsql/src/backend/postmaster/postmaster.c,v retrieving revision 1.476 diff -u -r1.476 postmaster.c --- src/backend/postmaster/postmaster.c 22 Nov 2005 18:17:18 - 1.476 +++ src/backend/postmaster/postmaster.c 10 Dec 2005 18:28:04 - @@ -254,6 +254,7 @@ static void ConnFree(Port *port); static void reset_shared(int port); static void SIGHUP_handler(SIGNAL_ARGS); +static void RunAtexitScriptFile(const char *); static void pmdie(SIGNAL_ARGS); static void reaper(SIGNAL_ARGS); static void sigusr1_handler(SIGNAL_ARGS); @@ -1856,6 +1858,21 @@ errno = save_errno; } +/* + * RunAtexitScriptFile -- run configured atexit script. + */ +static void +RunAtexitScriptFile(const char *shuttype) +{ + if (enable_atexit_script_file && atexit_script_file) + { + int l = strlen(atexit_script_file) + strlen(shuttype) + 2; + charbuf[l]; + + sprintf(buf, "%s %s", atexit_script_file, shuttype); + system(buf); + } +} /* * pmdie -- signal handler for processing various postmaster signals. @@ -1885,6 +1902,7 @@ Shutdown = SmartShutdown; ereport(LOG, (errmsg("received smart shutdown request"))); + RunAtexitScriptFile("smart"); /* * We won't wait out an autovacuum iteration ... @@ -1931,6 +1949,7 @@ Shutdown = FastShutdown; ereport(LOG, (errmsg("received fast shutdown request"))); + RunAtexitScriptFile("fast"); if (DLGetHead(BackendList) || AutoVacPID != 0) { @@ -1978,6 +1997,8 @@ */ ereport(LOG, (errmsg("received immediate shutdown request"))); + RunAtexitScriptFile("immediate"); + if (StartupPID != 0) kill(StartupPID, SIGQUIT); if (BgWriterPID != 0) Index: src/backend/utils/misc/guc.c === RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v retrieving revision 1.301 diff -u -r1.301 guc.c --- src/backend/utils/misc/guc.c22 Nov 2005 18:17:26 - 1.301 +++ src/backend/utils/misc/guc.c10 Dec 2005 18:28:24 - @@ -145,6 +145,7 @@ /* * GUC option variables that are exported from this module */ +bool enable_atexit_script_file = false; #ifdef USE_ASSERT_CHECKING bool assert_enabled = true; #endif @@ -181,6 +182,7 @@ char *HbaFileName; char *IdentFileName; char *external_pid_file; +char *atexit_script_file; inttcp_keepalives_idle; inttcp_keepalives_interval; @@ -391,6 +393,14 @@ static struct config_bool ConfigureNamesBool[] = { { + {"enable_atexit_script_file", PGC_POSTMASTER, FILE_LOCATIONS, + gettext_noop("Enables usage of atexit script file on postmaster shutdown."), + NULL + }, + &enable_atexit_script_file, + false, NULL, NULL + }, + { {"enable_seqscan", PGC_USERSET, QUERY_TUNING_METHOD, gettext_noop("Enables the planner's use of sequential-scan plans."), NULL @@ -2119,6 +2129,16 @@ NULL, assign_canonical_path, NULL }, + { + {"atexit_script_file", PGC_POSTMASTER, FILE_LOCATIONS, + gettext_noop("Executes specified atexit script file on database shutdown."), + NULL, + GUC_SUPERUSER_ONLY + }, + &atexit_script_file, +
Re: [PATCHES] mvcc.sgml make up
On 12/5/05, Tom Lane <[EMAIL PROTECTED]> wrote: > SELECT * FROM foo WHERE col > 4; > SELECT * FROM foo WHERE col > 5; Ofcourse two different SELECT queries are (probably) gonna return different results. If this is the point you want to underline in the documentation, just rip that sentence off. From the documentation: «Notice that two successive SELECT commands can see different data, even though they are within a single transaction, if other transactions commit changes during execution of the first SELECT.» It's not interesting to see "two different SELECT queries" will return different results. As I understand from the above statement, the point in here is that the "same SELECT queries" may return different results too. Anyway, this what I understand from documentation. I just tried to clarify the argument. If most of you think this just confuses more and wrong, than just ignore the patch. ---(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
Re: [PATCHES] mvcc.sgml make up
On 12/5/05, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Please explain why you think this change is useful. I've read related part of the documentation 4-5 times and couldn't figure out the main difference between phantom and nonrepeatable read. At last, I've googled and found an explanation in some Oracle documentation. You know, not only hackers reading PostgreSQL docs. For the second mvcc.sgml edit, there's a huge difference between "two successive SELECT commands" and "two successive same SELECT commands". ---(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] mvcc.sgml make up
Index: doc/src/sgml/mvcc.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v retrieving revision 2.53 diff -u -r2.53 mvcc.sgml --- doc/src/sgml/mvcc.sgml 7 Nov 2005 17:36:44 - 2.53 +++ doc/src/sgml/mvcc.sgml 5 Dec 2005 11:07:19 - @@ -109,6 +109,11 @@ search condition and finds that the set of rows satisfying the condition has changed due to another recently-committed transaction. + + Data you already read hasn't been changed in a phantom read, just more data + may return than before due to your query criteria. This differs a phantom + read from a nonrepeatable one. + @@ -246,10 +251,10 @@ executed within its own transaction, even though they are not yet committed.) In effect, a SELECT query sees a snapshot of the database as of the instant that that query -begins to run. Notice that two successive SELECT commands can -see different data, even though they are within a single transaction, if -other transactions -commit changes during execution of the first SELECT. +begins to run. Notice that two successive same SELECT +commands can see different data, even though they are within a single +transaction, if other transactions commit changes during execution of +the first SELECT. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Case Conversion Fix for MB Chars
Last minute edit: src/test/mb seems a little bit old. I've tested SQL files in src/test/mb/sql with the expected results in src/test/mb/expected manually and it worked. (Output files need a little bit editing, like removing lines similar to "CREATE TABLE".) But it'll be better if any EUC users will try 'em manually too. On 12/2/05, Bruce Momjian wrote: > Volkan YAZICI wrote: > > After Tom's advice (he was doubtful about the patch), while I was > > thinking about how to improve the spectrum of tests, decided to use > > src/test/mb. In the tests, patch just succeded for unicode and failed > > on big5, euc_cn, euc_jp, euc_kr, euc_tw, mule_internal, sjis > > encodings. Fails' reason can be my wrong configuration too. (I've made > > tests on a both unicode and latin-5 encoded databases.) > > Do those encodings even have uppercase letters? According to what IRC folks, yes. > People have talked about ICU but I don't know if anyone is working on it > now. Furthermore, there're some unofficial ICU patches for PostgreSQL around. Like the one @ http://people.freebsd.org/~girgen/postgresql-icu/README.html > I think the big problem is that while your patch works for some cases, > it fails for others As I mentioned in the above, it seems like it's working for other ones too. > and there is no good way to know/test which will > work and which will not. Is that accurate? You don't want to commit this patch because it breaks[*] EUC like encodings. But OTOH, it fixes LatinN and UNICODE encodings. I'm really wondering, while we're trying to protect the EUC encodings still working, why there's not any EUC users around to take care of EUC tests? Doesn't EUC have any problems? Do ILIKE, upper/lower work for them properly? [*] If I didn't make a mistake, manual tests succeded for EUC like encodings too. You can think the reverse of the subject too. Think LatinN and UNICODE as working and somebody submitted a patch which fixes EUC encodings by breaking the previous ones. What will be the reaction of PostgreSQL team in this situation? Regards. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Case Conversion Fix for MB Chars
On 12/1/05, Bruce Momjian wrote: > Where are we on this patch? Is it to be applied? After Tom's advice (he was doubtful about the patch), while I was thinking about how to improve the spectrum of tests, decided to use src/test/mb. In the tests, patch just succeded for unicode and failed on big5, euc_cn, euc_jp, euc_kr, euc_tw, mule_internal, sjis encodings. Fails' reason can be my wrong configuration too. (I've made tests on a both unicode and latin-5 encoded databases.) AFAIC, euc* encodings break latin-n and fixed latin-n encodings break euc*. Seems like a deadlock. Furthermore, I'm not aware of the status of ICU (will it be applied with 8.2?), thus we can go a way through like distributing latin-n fixed PostgreSQL sources/binaries on postgresql.org.tr. Regards. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Case Conversion Fix for MB Chars
On 11/27/05, Volkan YAZICI <[EMAIL PROTECTED]> wrote: > Tests made on an i686 with a > 2.6.12.5 kernel. Here's a short list of cases I tried with both latin5 > and unicode charsets: > - lower/upper functions with Turkish characters. > - ILIKE matches with both lower and upper case Turkish characters. > (Above testes succeeded for non-Turkish characters too.) I read the above paragraph again and realized the out of usability of it. Here's a modified one: Test's made on a Debian GNU/Linux (stable) 3.1 by patching src/backend/utils/adt/like.c (r1.62) and src/backend/utils/adt/oracle_compat.c (r1.64) files. Related software versions: - gcc-3.3 [3.3.5-13] - libc6-dev [2.3.2.ds1-22] - locales [2.3.2.ds1-22] Tried test cases using patched CVS HEAD: [For Latin5] $ usr/bin/initdb -D var/data $ LANG="tr_TR.ISO-8859-9" usr/bin/postmaster -D var/data $ usr/bin/createdb -E latin5 test_latin5 $ usr/bin/psql test_latin5 Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit test_latin5=# SHOW client_encoding; client_encoding - LATIN5 (1 row) test_latin5=# SELECT upper('abcdefgğhıijklmnoöprsştuüvyz qwx 0123456789'); upper --- ABCDEFGĞHIİJKLMNOÖPRSŞTUÜVYZ QWX 0123456789 (1 row) test_latin5=# SELECT test_latin5-# lower('ABCDEFGĞHIİJKLMNOÖPRSŞTUÜVYZ QWX 0123456789'); lower - abcdefgğhıijklmnoöprsştuüvyz qwx 0123456789 (1 row) test_latin5=# BEGIN; BEGIN test_latin5=# CREATE TEMP TABLE t (v varchar); CREATE TABLE test_latin5=# COPY t FROM stdin; Enter data to be copied followed by a newline. End with a backslash and a period on a line by itself. >> ı123 >> I123 >> i123 >> İ123 >> \. test_latin5=# SELECT v FROM t; v -- ı123 I123 i123 İ123 (4 rows) test_latin5=# SELECT v FROM t WHERE v ILIKE 'ı%'; v -- ı123 I123 (2 rows) test_latin5=# SELECT v FROM t WHERE v ILIKE 'I%'; v -- ı123 I123 (2 rows) test_latin5=# SELECT v FROM t WHERE v ILIKE 'i%'; v -- i123 İ123 (2 rows) test_latin5=# SELECT v FROM t WHERE v ILIKE 'İ%'; v -- i123 İ123 (2 rows) test_latin5=# ROLLBACK; ROLLBACK [For UNICODE] Same steps as above with LANG="tr_TR.UTF-8" and database/client encoding as UNICODE. Hope this tests help. Regards. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Case Conversion Fix for MB Chars
On 11/27/05, Tom Lane <[EMAIL PROTECTED]> wrote: > > Yes, indeed. I agree with you to find a proper solution for character > > set handling. But, IMHO, it's better to have a-patchy working system > > instead of a not working one. > > But you just agreed that it doesn't work. You get me wrong. I tried to to say it works for latin5 and unicode. When I look at the latin-n implementation of PostgreSQL, see that there doesn't exist a far difference between 'em. So there shouldn't be a problem with latin-n encodings. But, as I try to explain, I don't have so much knowledge on unicode characters and cannot claim an exact answer about it. > It might be that there are degrees of not-working-ness here, but before > adopting a partial solution I would like to see some reasoning why it > won't make things worse for other people. I think that what you are > proposing could lead to arbitrarily bad behavior (up to and including > server crashes) depending on what libc's toupper/tolower functions are > coded to do with out-of-range inputs. Furthermore, I just used the methods already in the code. If it'll cause any crashes in the server side, it won't be my fault. (Except logical errors I made.) > Exactly what cases have you tried, and on what platforms? I don't have a buildfarm at home. Tests made on an i686 with a 2.6.12.5 kernel. Here's a short list of cases I tried with both latin5 and unicode charsets: - lower/upper functions with Turkish characters. - ILIKE matches with both lower and upper case Turkish characters. (Above testes succeeded for non-Turkish characters too.) Regards. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Case Conversion Fix for MB Chars
On 11/27/05, Tom Lane <[EMAIL PROTECTED]> wrote: > Doesn't this just move the failure cases around? I don't think so. I've tried to fix every tolower/toupper related problem (depending on the MB characters) I found in the code. If there's still a problem with them, it should be related with the pg_wchar_tb concept in utils/mb/wchar.c (AFAIC, the last remaning part about this case conversion mess is the one related with PQfnumber - which needs a very different approach.) > The really fundamental problem is that tolower/toupper don't work > on wchar_t. Yes, indeed. I agree with you to find a proper solution for character set handling. But, IMHO, it's better to have a-patchy working system instead of a not working one. Put yourself in our position, we're trying to give enterprise solutions to our customers and ILIKE, lower/upper doesn't work in the product that we support. We can work with a small patch instead of waiting next releases for an exact solution to the problem. Regards. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Case Conversion Fix for MB Chars
[Sorry if the post is duplicated. But I don't receive and ACK from majordamo.] On 11/27/05, Tom Lane <[EMAIL PROTECTED]> wrote: > Doesn't this just move the failure cases around? I don't think so. I've tried to fix every tolower/toupper related problem (depending on the MB characters) I found in the code. If there's still a problem with them, it should be related with the pg_wchar_tb concept in utils/mb/wchar.c (AFAIC, the last remaning part about this case conversion mess is the one related with PQfnumber - which needs a very different approach.) > The really fundamental problem is that tolower/toupper don't work > on wchar_t. Yes, indeed. I agree with you to find a proper solution for character set handling. But, IMHO, it's better to have a-patchy working system instead of a not working one. Put yourself in our position, we're trying to give enterprise solutions to our customers and ILIKE, lower/upper doesn't work in the product that we support. We can work with a small patch instead of waiting next releases for an exact solution to the problem. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Case Conversion Fix for MB Chars
Last minute edit: On 11/26/05, Volkan YAZICI <[EMAIL PROTECTED]> wrote: - In tests it succeeded for Turkish characters while using LATIN5 - encoding. But when encoding is UNICODE it still doesn't work. (IMHO, - for latin-N encodings there will be no compatibility problems; for - Unicode, I've no idea.) + In tests it succeeded for Turkish characters while using both + LATIN5 and UNICODE encodings. Furthermore, it shouldn't raise + any compatibility problems for LATIN-N encodings, but for + UNICODE, I don't have an exact idea. Regards. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] Case Conversion Fix for MB Chars
Here's small patch to fix case conversion problems for ILIKE and (Oracle Compat.) lower/upper functions. (Related bug report is here: http://archives.postgresql.org/pgsql-bugs/2005-10/msg1.php) In tests it succeeded for Turkish characters while using LATIN5 encoding. But when encoding is UNICODE it still doesn't work. (IMHO, for latin-N encodings there will be no compatibility problems; for Unicode, I've no idea.) Regards. case_conversion.patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] palloc check for pg_md5_encrypt
This is the 4th time sending this patch. Hope this one succeeds. Index: md5.c === RCS file: /projects/cvsroot/pgsql/src/backend/libpq/md5.c,v retrieving revision 1.30 diff -u -r1.30 md5.c --- md5.c 17 Oct 2005 16:24:19 - 1.30 +++ md5.c 18 Oct 2005 19:47:24 - @@ -328,6 +328,9 @@ char *crypt_buf = palloc(passwd_len + salt_len); boolret; + if (!crypt_buf) + return false; + /* * Place salt at the end because it may be known by users trying to crack * the MD5 output. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] PQmakeEmptyPGresult() will return NULL if allocation fails
PQmakeEmptyPGresult() will return NULL if malloc() fails for required PGresult struct. Index: doc/src/sgml/libpq.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.184 diff -u -c -r1.184 libpq.sgml *** doc/src/sgml/libpq.sgml 10 Jun 2005 03:02:01 - 1.184 --- doc/src/sgml/libpq.sgml 10 Jun 2005 06:45:28 - *** *** 1657,1663 This is libpq's internal function to allocate and initialize an empty ! PGresult object. It is exported because some applications find it useful to generate result objects (particularly objects with error status) themselves. If conn is not null and status indicates an error, the current error message of the specified connection is copied into the PGresult. --- 1657,1664 This is libpq's internal function to allocate and initialize an empty ! PGresult object. Function will return NULL if required memory ! couldn't be allocated. It is exported because some applications find it useful to generate result objects (particularly objects with error status) themselves. If conn is not null and status indicates an error, the current error message of the specified connection is copied into the PGresult. Index: src/interfaces/libpq/fe-exec.c === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.139 diff -u -c -r1.139 fe-exec.c *** src/interfaces/libpq/fe-exec.c 21 Jun 2003 21:51:34 - 1.139 --- src/interfaces/libpq/fe-exec.c 10 Jun 2005 06:45:30 - *** *** 130,135 --- 130,137 PGresult *result; result = (PGresult *) malloc(sizeof(PGresult)); + if (!result) + return NULL; result->ntups = 0; result->numAttributes = 0; ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] PQgetGetCopyData() doc. and PQsendQueryGuts() SegFault handling fix.
Fixed PQconsumeInput() usage for PQgetCopyData() in libpq.sgml. (Related mail thread: http://archives.postgresql.org/pgsql-novice/2005-06/msg00038.php) Fixed SegFault in PQsendQueryGuts() when user submitted a binary parameter without size. And 2 typo fixes. Index: doc/src/sgml/libpq.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.182 diff -u -c -r1.182 libpq.sgml *** doc/src/sgml/libpq.sgml 4 Jun 2005 20:42:41 - 1.182 --- doc/src/sgml/libpq.sgml 7 Jun 2005 15:43:51 - *** *** 3230,3237 When async is true (not zero), PQgetCopyData will not block waiting for input; it will return zero if the COPY is still in progress but no complete row is available. (In this case wait for ! read-ready before trying again; it does not matter whether you call ! PQconsumeInput.) When async is false (zero), PQgetCopyData will block until data is available or the operation completes. --- 3230,3237 When async is true (not zero), PQgetCopyData will not block waiting for input; it will return zero if the COPY is still in progress but no complete row is available. (In this case wait for ! read-ready and then call PQconsumeInput before calling ! PQgetCopyData again.) When async is false (zero), PQgetCopyData will block until data is available or the operation completes. Index: src/interfaces/libpq/fe-exec.c === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.167 diff -u -c -r1.167 fe-exec.c *** src/interfaces/libpq/fe-exec.c 29 Apr 2005 13:42:21 - 1.167 --- src/interfaces/libpq/fe-exec.c 7 Jun 2005 15:44:00 - *** *** 30,36 #endif /* keep this in same order as ExecStatusType in libpq-fe.h */ ! char *const pgresStatus[] = { "PGRES_EMPTY_QUERY", "PGRES_COMMAND_OK", "PGRES_TUPLES_OK", --- 30,36 #endif /* keep this in same order as ExecStatusType in libpq-fe.h */ ! char *const pgresStatus[] = { "PGRES_EMPTY_QUERY", "PGRES_COMMAND_OK", "PGRES_TUPLES_OK", *** *** 960,966 if (paramFormats && paramFormats[i] != 0) { /* binary parameter */ ! nbytes = paramLengths[i]; } else { --- 960,975 if (paramFormats && paramFormats[i] != 0) { /* binary parameter */ ! if ( paramLengths ) ! { ! nbytes = paramLengths[i]; ! } ! else ! { ! printfPQExpBuffer(&conn->errorMessage, ! libpq_gettext("you have to specify size for binary formats.\n")); ! goto sendFailed; ! } } else { Index: src/interfaces/libpq/libpq-fe.h === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/libpq-fe.h,v retrieving revision 1.116 diff -u -c -r1.116 libpq-fe.h *** src/interfaces/libpq/libpq-fe.h 31 Dec 2004 22:03:50 - 1.116 --- src/interfaces/libpq/libpq-fe.h 7 Jun 2005 15:44:00 - *** *** 156,162 char *fieldSep; /* field separator */ char *tableOpt; /* insert to HTML */ char *caption; /* HTML */ ! char **fieldName; /* null terminated array of repalcement * field names */ } PQprintOpt; --- 156,162 char *fieldSep; /* field separator */ char *tableOpt; /* insert to HTML */ char *caption; /* HTML */ ! char **fieldName; /* null terminated array of replacement * field names */ } PQprintOpt; ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq