Re: [PATCHES] Configurable Penalty Costs for Levenshtein

2008-04-03 Thread Volkan YAZICI
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

2008-04-02 Thread Volkan YAZICI
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

2008-03-23 Thread Volkan YAZICI
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

2007-11-28 Thread Volkan YAZICI
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

2007-11-01 Thread Volkan YAZICI
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

2007-10-17 Thread Volkan YAZICI
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

2006-04-02 Thread Volkan YAZICI
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

2006-04-02 Thread Volkan YAZICI
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

2006-03-12 Thread Volkan YAZICI
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

2006-03-01 Thread Volkan YAZICI
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

2005-12-30 Thread Volkan YAZICI
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

2005-12-23 Thread Volkan YAZICI
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

2005-12-22 Thread Volkan YAZICI
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

2005-12-18 Thread Volkan YAZICI
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)

2005-12-10 Thread Volkan YAZICI
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

2005-12-05 Thread Volkan YAZICI
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

2005-12-05 Thread Volkan YAZICI
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

2005-12-05 Thread Volkan YAZICI

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

2005-12-02 Thread Volkan YAZICI
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

2005-12-02 Thread Volkan YAZICI
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

2005-11-28 Thread Volkan YAZICI
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

2005-11-27 Thread Volkan YAZICI
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

2005-11-27 Thread Volkan YAZICI
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

2005-11-27 Thread Volkan YAZICI
[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

2005-11-26 Thread Volkan YAZICI
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

2005-11-26 Thread Volkan YAZICI
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

2005-10-20 Thread Volkan YAZICI
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

2005-06-10 Thread Volkan YAZICI
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.

2005-06-07 Thread Volkan YAZICI
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