Re: [PATCHES] Patch to be verbose about being unable to read
Sean Chittenden writes: > Agreed, though one train of thought is that if someone did put a > .pgpass file in place that isn't readable, it should be known that > their efforts are being wasted in vein. I tried making several dot-files I found in my home directory unreadable (or unsearchable, in case of a directory): acrorc, antrc, bashrc, cvsrc, fetchmailrc, inputrc, licq, mozilla, psqlrc, rpmmacros, Xmodmap, xemacs, xmms. Bash gave me warning, fetchmail gave me an error (which is reasonable, because fetchmail doesn't work without configuration), and the rest just ignored the file. Open password and private key files might give different results, but as far as unreadable files go, I say ignore them. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Patch for psql to avoid altering the PGresult strings
The mbvalidate() function was called on the PGresult strings, and it
changes the strings (removes unknown characters).
I've change the validation function to one that either returns a new
string when needed or NULL when the string already was validating. The
normal case is to have validating strings so in most cases no new strings
are created.
I have not included changes to avoid sending non validating strings to the
server. It's not clear what is the best way to solve it. Maybe one should
just do a stupid fix for 7.4 and validate the strings like above and just
delete non validating strings. It is possible to solve it in a better way,
but it's more complicated. We have 4 different charsets to think about in
psql. The server, the client, the terminal and the message catalog (the
last two usually matches, but not always). I would prefer to find a good
solution instead of just patching one small problem after another.
--
/Dennis
Index: mbprint.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/mbprint.c,v
retrieving revision 1.6
diff -u -r1.6 mbprint.c
--- mbprint.c 18 Mar 2003 22:15:44 - 1.6
+++ mbprint.c 21 Jun 2003 14:34:53 -
@@ -192,7 +192,7 @@
/* mb_utf_wcwidth : calculate column length for the utf8 string pwcs
*/
static int
-mb_utf_wcswidth(unsigned char *pwcs, size_t len)
+mb_utf_wcswidth(const unsigned char *pwcs, size_t len)
{
int w,
l = 0;
@@ -269,29 +269,42 @@
return -1;
}
+static bool
+mb_utf_is_valid(const unsigned char *pwcs)
+{
+ while (*pwcs)
+ {
+ if (utf_charcheck(pwcs++) < 0)
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
static unsigned char *
-mb_utf_validate(unsigned char *pwcs)
+mb_mk_valid_utf_string(const unsigned char *pwcs)
{
+ /* Exact length we need for p is unknown.
+* All we know is that it's shorter then pwcs.
+*/
int l = 0;
- unsigned char *p = pwcs;
- unsigned char *p0 = pwcs;
+ unsigned char *p = malloc(strlen(pwcs));
+ unsigned char *p0 = p;
+
+ if (!p)
+ {
+ perror("malloc");
+ exit(EXIT_FAILURE);
+ }
while (*pwcs)
{
if ((l = utf_charcheck(pwcs)) > 0)
{
- if (p != pwcs)
- {
- int i;
-
- for (i = 0; i < l; i++)
- *p++ = *pwcs++;
- }
- else
- {
- pwcs += l;
- p += l;
- }
+ int i;
+
+ for (i = 0; i < l; i++)
+ *p++ = *pwcs++;
}
else
{
@@ -299,8 +312,9 @@
pwcs++;
}
}
- if (p != pwcs)
- *p = '\0';
+
+ *p = '\0';
+
return p0;
}
@@ -309,7 +323,7 @@
*/
int
-pg_wcswidth(unsigned char *pwcs, size_t len, int encoding)
+pg_wcswidth(const unsigned char *pwcs, size_t len, int encoding)
{
if (encoding == PG_UTF8)
return mb_utf_wcswidth(pwcs, len);
@@ -323,17 +337,27 @@
}
}
+/*
+ * This function either returns a new allocated string
+ * that is valid or it returns NULL which indicates that
+ * the original string was already valid (the common case).
+ */
unsigned char *
-mbvalidate(unsigned char *pwcs, int encoding)
+mbvalidate(const unsigned char *pwcs, int encoding)
{
if (encoding == PG_UTF8)
- return mb_utf_validate(pwcs);
+ {
+ if (mb_utf_is_valid(pwcs))
+ return NULL;
+ else
+ return mb_mk_valid_utf_string(pwcs);
+ }
else
{
/*
* other encodings needing validation should add their own
* routines here
*/
- return pwcs;
+ return NULL;
}
}
Index: mbprint.h
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/mbprint.h,v
retrieving revision 1.6
diff -u -r1.6 mbprint.h
--- mbprint.h 18 Mar 2003 22:15:44 - 1.6
+++ mbprint.h 21 Jun 2003 14:34:53 -
@@ -6,8 +6,8 @@
pg_wchar utf2ucs(const unsigned char *c);
-unsigned char *mbvalidate(unsigned char *pwcs, int encoding);
+unsigned char *mbvalidate(const unsigned char *pwcs, int encoding);
-intpg_wcswidth(unsigned char *pwcs, size_t len, int encoding);
+intpg_wcswidth(const unsigned char *pwcs, size_t len, int
encoding);
#end
Re: [PATCHES] Thread configure flag
Peter Eisentraut wrote: > Bruce Momjian writes: > > > First, ecpg has actual thead creation function calls, so I believe we > > will still need a --with-threads configure option, at least to control > > ecpg, unless we make threading some kind of ecpg runtime flag. > > This is not an issue because it only affects the libecpg library. So we would just have a libecpg and a libecpg_r? OK. > > So, if we move in the libpq_r direction, we will have some platforms > > that don't have libpq_r because they don't need it, and others that > > don't have it because they don't support threading or we don't know how > > to do threading in our configure tests. This seems very confusing to > > me. > > On a system with a separate libc_r, you *already* need special compiler > flags to link thread-safe applications. So it is only consistent that > libpq applications also need special flags. For example, a normal > application is linked so: > > cc -o prog prog1.o prog2.o -lpq -lc > > (well, you don't write the -lc) and a thread-safe application is linked > so: > > cc -o prog prog1.o prog2.o -lpq_r -lc_r OK, I am now wondering if we should just create non-thread libpq by default, and create threaded libpq for non-libc_r platforms and libpq and libpq_r for libc_r platforms, and of course fail on platforms where we don't know how to do threading. How is that? > > I wonder if we should just keep the current setup for 7.4 and > > collect theading configure information, then revisit this for 7.5. > > Well, when the packagers wrap up 7.4 they're going to need to make a call. > Either it's not going to be thread-safe, and the work was in vain, or it's > thread-safe and the concerns about the supposed performance hits are not > addressed. Well, it will not be in vain because people can still compile their own builds. I am not sure if we support enough platforms to enable all this by default in 7.4, and it could cause confusion. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Thread configure flag
--On Saturday, June 21, 2003 15:57:54 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: \ Well, when the packagers wrap up 7.4 they're going to need to make a call. Either it's not going to be thread-safe, and the work was in vain, or it's thread-safe and the concerns about the supposed performance hits are not addressed. Well, it will not be in vain because people can still compile their own builds. I am not sure if we support enough platforms to enable all this by default in 7.4, and it could cause confusion. Did anyone see my comments about -Kthread/-Kpthread on UnixWare? That throws another mix into it. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[PATCHES] pg_hba.conf CIDR mask doc patch
And here it is. - Original Message - From: Andrew Dunstan To: PG Patches Sent: Thursday, June 19, 2003 7:51 PM Subject: [PATCHES] pg_hba.conf.sample Here's a small patch to pg_hba.conf.sample that explains the use of CIDR addresses. I'm still working on a patch to the regular docs. cheers andrew cidr-doc.patch Description: Binary data ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] typo in arch-dev.sgml
libpg should be libpq -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc Index: doc/src/sgml/arch-dev.sgml === RCS file: /home/rbt/work/postgresql/cvs/pgsql-server/doc/src/sgml/arch-dev.sgml,v retrieving revision 2.19 diff -c -r2.19 arch-dev.sgml *** doc/src/sgml/arch-dev.sgml 25 Mar 2003 16:15:35 - 2.19 --- doc/src/sgml/arch-dev.sgml 22 Jun 2003 00:34:52 - *** *** 142,148 The client process can either be the psql frontend (for interactive SQL queries) or any user application implemented using ! the libpg library. Note that applications implemented using ecpg (the PostgreSQL embedded SQL preprocessor for C) also use this library. --- 142,148 The client process can either be the psql frontend (for interactive SQL queries) or any user application implemented using ! the libpq library. Note that applications implemented using ecpg (the PostgreSQL embedded SQL preprocessor for C) also use this library. signature.asc Description: This is a digitally signed message part
Re: [PATCHES] typo in arch-dev.sgml
Rod Taylor <[EMAIL PROTECTED]> writes: > libpg should be libpq Done (along with a lot of other editorializing that this file has been in desperate need of for a long while ...) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
