Re: [PATCHES] more code cleanup
On Tue, 2004-10-12 at 11:44, Neil Conway wrote: > This patch makes another set of small cosmetic improvements [...] Applied to HEAD. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] contrib/xml,xml2 code cleanup
On Tue, 2004-10-12 at 11:29, Neil Conway wrote: > This patch cleans up some unnecessary void * casts in contrib/xml and > contrib/xml2. Applied to HEAD. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] PGPASSWORD and client tools
This has been saved for the 8.1 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 --- Andrew Dunstan wrote: > > Here's a patch that I think (hope) does this right, by using the file > pointed to by the environment var PGPASSFILE, if set, in preference to > $HOME/.pgpass. I assume that at this stage it would be held over for 8.1 > as a new feature - if not I'll put together some docco in a hurry. > > cheers > > andrew > > > > Andrew Dunstan wrote: > > > > > > > Tom Lane wrote: > > > >> Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> > >> > >>> How about an environment variable that points to a .pgpass type file. > >>> > >> > >> > >> You can do that today: point $HOME at some temp directory or other. > >> AFAIR pg_dump doesn't make any other use of $HOME ... > >> > >> > >> > >>> Or we could even play games with PGPASSWORD - if it names an > >>> existing file that satisfies the .pgpass criteria then it will be > >>> taken as the location of the .pgpass file instead of $HOME/.pgpass - > >>> otherwise its value will be considered to be the password itself. > >>> > >> > >> > >> Gaack... if you want a separate variable, we can talk about that, but > >> let's not overload PGPASSWORD like that. Consider even just the > >> implications of whether libpq error messages should echo back the > >> "filename" ... > >> > >> > >> > >> > > > > Yeah. as usual you're right :-) > > > > So let's go woth PGPASSFILE > > > > cheers > > > > andrew > > > > ---(end of broadcast)--- > > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] pg_restore - added documentation
Peter Eisentraut wrote:
> Harald Armin Massa wrote:
> > --
> > Usage:
> > pg_restore [OPTION]... [FILE]
> >
> > General options:
> > -d, --dbname=NAMEoutput database name (to restore into a psql
> > database)
> > -f, --file=FILENAME output file name (to convert custom/tar to
> > plain SQL)
> > -F, --format=c|t specify backup file format (custom or tar,
> > plain text is not possible)
> > --
>
> These lines are too long for help output. Also, there is no such thing
> as a "psql database".
Agreed.
However, I wonder if "output database" is the proper name for -d? Isn't
it more "restore database" or "target database"? Output makes me think
of pg_dump.
pg_restore manual page has for -d:
--dbname=dbname
Connect to database dbname and restore directly
into the database.
No mention of "output" there.
I have updated some of the help wording for pg_restore which should clarify
things.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/pg_dump/pg_restore.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_restore.c,v
retrieving revision 1.62
diff -c -c -r1.62 pg_restore.c
*** src/bin/pg_dump/pg_restore.c12 Oct 2004 21:54:44 - 1.62
--- src/bin/pg_dump/pg_restore.c13 Oct 2004 00:40:10 -
***
*** 360,366
printf(_(" %s [OPTION]... [FILE]\n"), progname);
printf(_("\nGeneral options:\n"));
! printf(_(" -d, --dbname=NAMEoutput database name\n"));
printf(_(" -f, --file=FILENAME output file name\n"));
printf(_(" -F, --format=c|t specify backup file format\n"));
printf(_(" -i, --ignore-version proceed even when server version
mismatches\n"));
--- 360,366
printf(_(" %s [OPTION]... [FILE]\n"), progname);
printf(_("\nGeneral options:\n"));
! printf(_(" -d, --dbname=NAMErestore database name\n"));
printf(_(" -f, --file=FILENAME output file name\n"));
printf(_(" -F, --format=c|t specify backup file format\n"));
printf(_(" -i, --ignore-version proceed even when server version
mismatches\n"));
***
*** 369,382
printf(_(" --help show this help, then exit\n"));
printf(_(" --versionoutput version information, then
exit\n"));
! printf(_("\nOptions controlling the output content:\n"));
printf(_(" -a, --data-only restore only the data, no schema\n"));
printf(_(" -c, --clean clean (drop) schema prior to create\n"));
printf(_(" -C, --create issue commands to create the
database\n"));
printf(_(" -I, --index=NAME restore named index\n"));
printf(_(" -L, --use-list=FILENAME use specified table of contents for
ordering\n"
" output from this file\n"));
! printf(_(" -O, --no-owner do not output commands to set object
ownership\n"));
printf(_(" -P, --function=NAME(args)\n"
" restore named function\n"));
printf(_(" -s, --schema-onlyrestore only the schema, no data\n"));
--- 369,382
printf(_(" --help show this help, then exit\n"));
printf(_(" --versionoutput version information, then
exit\n"));
! printf(_("\nOptions controlling the restore:\n"));
printf(_(" -a, --data-only restore only the data, no schema\n"));
printf(_(" -c, --clean clean (drop) schema prior to create\n"));
printf(_(" -C, --create issue commands to create the
database\n"));
printf(_(" -I, --index=NAME restore named index\n"));
printf(_(" -L, --use-list=FILENAME use specified table of contents for
ordering\n"
" output from this file\n"));
! printf(_(" -O, --no-owner do not issue commands to set object
ownership\n"));
printf(_(" -P, --function=NAME(args)\n"
" restore named function\n"));
printf(_(" -s, --schema-onlyrestore only the schema, no data\n"));
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] libpq.dll on win32
Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Yes, but it's not in there by default. >> If we're going to require a third party tool to be installed, we'd >> probably be better off requiring a simple sed.exe which is a single >> binary instead of the whole perl package which is hundreds of files and >> many megabytes... > Try this then: http://gnuwin32.sourceforge.net/packages/sed.htm (almost > a single binary, anyway) This is all pretty silly. We should just build the .def files during tarball construction, much as we handle bison/flex stuff. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] libpq.dll on win32
Magnus Hagander wrote: The avaiable options to do it are just horrible. There is edlin, but it can't be used for anything serious. Or there is the wonderful concept of writing something in vbscript. But putting vbscript in there doesn't seem like a very good option. ActiveState Perl? It's very widely used. Yes, but it's not in there by default. If we're going to require a third party tool to be installed, we'd probably be better off requiring a simple sed.exe which is a single binary instead of the whole perl package which is hundreds of files and many megabytes... Try this then: http://gnuwin32.sourceforge.net/packages/sed.htm (almost a single binary, anyway) cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] libpq.dll on win32
>>The avaiable options to do it are just horrible. There is >edlin, but it >>can't be used for anything serious. Or there is the wonderful >concept of >>writing something in vbscript. But putting vbscript in there doesn't >>seem like a very good option. >> >> >> > >ActiveState Perl? It's very widely used. > Yes, but it's not in there by default. If we're going to require a third party tool to be installed, we'd probably be better off requiring a simple sed.exe which is a single binary instead of the whole perl package which is hundreds of files and many megabytes... //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] libpq.dll on win32
Magnus Hagander wrote: (We really oughta figure a way to generate them all from a single list file... can we rely on sed(1) being available in all Windows build environments?) Unfortunatly, no, we can't. There are sed implementations available for win32, but they're not installed by default. MingW and Cygwin of course ship with sed, but we build libpq with MSVC and Borland as well... The avaiable options to do it are just horrible. There is edlin, but it can't be used for anything serious. Or there is the wonderful concept of writing something in vbscript. But putting vbscript in there doesn't seem like a very good option. ActiveState Perl? It's very widely used. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] libpq.dll on win32
>*** src/interfaces/libpq/fe-secure.c 28 Sep 2004 00:06:02
>- 1.54
>--- src/interfaces/libpq/fe-secure.c 11 Oct 2004 19:50:22 -
>***
>*** 1201,1206
>--- 1201,1212
> return NULL;
> return conn->ssl;
> }
>+ #else
>+ void *
>+ PQgetssl(PGconn *conn)
>+ {
>+ return NULL;
>+ }
> #endif /* USE_SSL */
>
>
>This seems like a good idea, but that particular approach to it will
>draw an unprototyped-global-function warning on every non-SSL-enabled
>compile ... please clean it up.
Oops. Updated patch attached.
>Also, I count 3 *.def files to be fixed, not two.
Right. The Borland one, forgot all about that one. Included in attached
patch. Borland version not actually tested, though, since I don't have
Borland C..
> (We really oughta
>figure a way to generate them all from a single list file... can we
>rely on sed(1) being available in all Windows build environments?)
Unfortunatly, no, we can't.
There are sed implementations available for win32, but they're not
installed by default. MingW and Cygwin of course ship with sed, but we
build libpq with MSVC and Borland as well...
The avaiable options to do it are just horrible. There is edlin, but it
can't be used for anything serious. Or there is the wonderful concept of
writing something in vbscript. But putting vbscript in there doesn't
seem like a very good option.
I like the idea of having it built automatically for the snapshots in
some way, and if you want to build it manually, you have to install
'sed'. I think that's a reasonable requirement.
Anyway. Here is the patch for this one. Not sure we want to muck around
with those build issues during beta considering they actually *work* now
(if a bit of extra work).
//Magnus
libpq_def.patch
Description: libpq_def.patch
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] pg_config translation to pt_BR
Euler Taveira de Oliveira wrote: > Here is a patch to available the first translation of pg_config. The > files attached needs to be in src/bin/pg_config. Basically, it is two > files (nls.mk, pt_BR.po) and one directory (po/). Installed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] (Turkish) New translation: pg_resetxlog, Updated translation: pg_ctl
Devrim GUNDUZ wrote: > I've fully translated pg_resetxlog into Turkish (new translation). > Also, updated pg_ctl translation to 100% : Both installed. > BTW, on http://developer.postgresql.org/~petere/nlsstatus/#tcurrent , > Turkish translation of pg_controldata seems 95%, but on my side: > > $ msgfmt -o /dev/null -v -c pg_controldata-tr.pot > 41 translated messages. The PO files you download from that web site are *not* the PO files that are in the CVS repository. They are merged against the latest program sources, so if something changes in the program, messages go fuzzy or obsolete. Indeed I see two fuzzy messages in that particular file. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] libpq.dll on win32
Reini Urban <[EMAIL PROTECTED]> writes: > Tom Lane schrieb: >> Also, I count 3 *.def files to be fixed, not two. (We really oughta >> figure a way to generate them all from a single list file... can we >> rely on sed(1) being available in all Windows build environments?) > for cygwin: yes. > the non-gcc builds would need the mingw or cygwin versions. A workable plan B would be to keep a single list file in CVS and build the *.def files as derived files that we include in the distribution tarball (same principle as for bison/flex output files). regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Translation update for 8.0: psql-ru
Serguei Mokhov wrote: > A new string transladed. Please install. Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Translation updates fo 7.4/8.0: postgres-ru
Serguei Mokhov wrote: > Another chunk. Please apply to both, 7.4 and 8.0 Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] libpq.dll on win32
Tom Lane schrieb: Also, I count 3 *.def files to be fixed, not two. (We really oughta figure a way to generate them all from a single list file... can we rely on sed(1) being available in all Windows build environments?) for cygwin: yes. the non-gcc builds would need the mingw or cygwin versions. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Casting INT4 to BOOL...
Sean Chittenden said: > Perl's > decision to let any non-empty string be true doesn't mean a database > should take any nonfalse-like value and assume it should be true. > 42::BOOL == TRUE, on the other hand, has a long mathematical president > wherein non-zero values are true and zero values are false. > (ITMY precedent) FYI, perl does not quite do this. Both "" and "0" are false. Any other string is true. Of course, the Unix shell treats an exit value of 0 as success and non-zero as failure, so the rule is hardly universal. Personally, I would prefer to make boolean as opaque as possible. But I don't care that much. > > > ... I wonder what color this bikeshed is gunna be... purple. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [pgsql-hackers-win32] Static build of libpq fails
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: 12 October 2004 02:08 > To: Dave Page > Cc: [EMAIL PROTECTED]; PostgreSQL-patches > Subject: Re: [pgsql-hackers-win32] Static build of libpq fails > > Dave Page wrote: > > Hi, > > > > I tried building a static libpq with Mingw, which it seems doesn't > > work any more: > > > > make[3]: *** No rule to make target `libpq.a', needed by > > `all-static-lib'. Stop. > > make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq' > > make[2]: *** [all] Error 2 > > make[2]: Leaving directory `/cvs/pgsql/src/interfaces' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory `/cvs/pgsql/src' > > make: *** [all] Error 2 > > > > I can work around this easily enough, however it should > obviously get > > fixed at some point. > > I got it working easily by doing 'gmake all-static-lib' from > the src/interfaces/libpq directory. Is it supposed to work > somewhere else? $ ./configure --disable-shared; make all Will fail (and still does with cvs tip). I normally use that on Linux - I assume it should also work on Mingw. Regards, Dave ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Casting INT4 to BOOL...
The patch treats any non-zero value as "true". Is that the behavior
we
want, or should we only allow "1" as an integer representation of
"true"? (I'm not sure myself, I just don't think copying C here is
necessarily the best guide.)
I would posit that this is the desired behavior as it's consistent
with
every language I can think of.
However, AFAIK it's inconsitent with the type input function which
supports '1' and '0' but not other integers.
I actually pondered that and came up with a patch that I didn't submit.
False has a very specific set of possibilities that can be reasonably
easily defined. True, is anything not false. I eventually didn't
submit it because I was able to convince myself with the following
statement.
Regardless of whether or not true is any non-zero value, this is a
database where data and its inputs must be validated and constrained to
a given set of probable and process-able possibilities. Perl's
decision to let any non-empty string be true doesn't mean a database
should take any nonfalse-like value and assume it should be true.
42::BOOL == TRUE, on the other hand, has a long mathematical president
wherein non-zero values are true and zero values are false.
Unlike the previous int4_bool()/bool_int4() patch which addresses a
mathematical technicality, accepting different string values as true or
false seems exceedingly dangerous, though probably an okay
interpretation. I went one step further, however, and tested for an
empty string as a valid false value (one of Perl's false values).
Since this subject isn't ever going to get resolved, I don't think it's
worth trudging down this path, but, I thought the extreme is helpful in
justifying the current string->bool conversion and the new
int4->bool/bool->int4 conversion, IMHO. -sc
... I wonder what color this bikeshed is gunna be...
Index: bool.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/bool.c,v
retrieving revision 1.35
diff -u -r1.35 bool.c
--- bool.c 29 Aug 2004 05:06:49 - 1.35
+++ bool.c 12 Oct 2004 07:52:14 -
@@ -37,29 +37,12 @@
switch (*b)
{
- case 't':
- case 'T':
- if (pg_strncasecmp(b, "true", strlen(b)) == 0)
- PG_RETURN_BOOL(true);
- break;
-
case 'f':
case 'F':
if (pg_strncasecmp(b, "false", strlen(b)) == 0)
PG_RETURN_BOOL(false);
break;
- case 'y':
- case 'Y':
- if (pg_strncasecmp(b, "yes", strlen(b)) == 0)
- PG_RETURN_BOOL(true);
- break;
-
- case '1':
- if (pg_strncasecmp(b, "1", strlen(b)) == 0)
- PG_RETURN_BOOL(true);
- break;
-
case 'n':
case 'N':
if (pg_strncasecmp(b, "no", strlen(b)) == 0)
@@ -70,17 +53,11 @@
if (pg_strncasecmp(b, "0", strlen(b)) == 0)
PG_RETURN_BOOL(false);
break;
-
- default:
- break;
+ case '\0':
+ PG_RETURN_BOOL(false);
}
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
-errmsg("invalid input syntax for type boolean: \"%s\"", b)));
-
- /* not reached */
- PG_RETURN_BOOL(false);
+ PG_RETURN_BOOL(true);
}
/*
--
Sean Chittenden
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] libpq.dll on win32
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: 12 October 2004 01:38 > To: Magnus Hagander > Cc: pgsql-patches > Subject: Re: [PATCHES] libpq.dll on win32 > > Also, I count 3 *.def files to be fixed, not two. (We really > oughta figure a way to generate them all from a single list > file... can we rely on sed(1) being available in all Windows > build environments?) I could have sworn there used to be 4 .def files - 2 for VC++ and 2 for Borland. Oh well. Anyway, no, sed will not be available in VC++, or (I guess) Borland environments. Regards, Dave ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] libpq.dll on win32
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Magnus Hagander > Sent: 11 October 2004 21:05 > To: pgsql-patches > Subject: [PATCHES] libpq.dll on win32 > > * Adds required functions to libpqdll.def and libpqddll.def. > This includes the functions not in the libpq API that are > used by initdb and imported from libpq.dll (per recent mail > discussion) They should be added to the Borland .def files as well. Regards, Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Casting INT4 to BOOL...
Am Montag, 11. Oktober 2004 15:50 schrieb Tom Lane: > I agree with Michael's position. I don't like implicit/automatic casts > any more than Peter does, but I don't see a strong argument against > providing explicit casts. I find the chosen mapping to be somewhat arbitrary and artifical. (2::int => '2'::text is not arbitrary in my mind, but 1::int => true is just something a C programmer could make up.) But I'm clearly in the minority here. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
