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] 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] 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)));
! /*
! * If either rows or cols is 0, the answer is the other value. This makes
! * sense
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, -) == 0
||
!
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);
***
*** 400,407
[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,
+ NULL, assign_canonical_path,
[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. /para + para + 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. + /para /listitem /varlistentry /variablelist @@ -246,10 +251,10 @@ executed within its own transaction, even though they are not yet committed.) In effect, a commandSELECT/command query sees a snapshot of the database as of the instant that that query -begins to run. Notice that two successive commandSELECT/command commands can -see different data, even though they are within a single transaction, if -other transactions -commit changes during execution of the first commandSELECT/command. +begins to run. Notice that two successive same commandSELECT/command +commands can see different data, even though they are within a single +transaction, if other transactions commit changes during execution of +the first commandSELECT/command. /para para ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
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
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] Case Conversion Fix for MB Chars
On 12/1/05, Bruce Momjian pgman@candle.pha.pa.us 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
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 pgman@candle.pha.pa.us 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 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
[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
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
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
[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
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] 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 para This is applicationlibpq/'s internal function to allocate and initialize an empty ! structnamePGresult/structname object. It is exported because some applications find it useful to generate result objects (particularly objects with error status) themselves. If parameterconn/parameter is not null and parameterstatus/ indicates an error, the current error message of the specified connection is copied into the structnamePGresult/structname. --- 1657,1664 para This is applicationlibpq/'s internal function to allocate and initialize an empty ! structnamePGresult/structname 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 parameterconn/parameter is not null and parameterstatus/ indicates an error, the current error message of the specified connection is copied into the structnamePGresult/structname. 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
