[PATCHES] update for brazilian portuguese translation

2004-01-07 Thread Euler Taveira de Oliveira
Hi, I have updated the brazilian portuguese translation. I just revised libpq, psql, pg_dump, pgscripts, pg_controldata, pg_resetxlog and jdbc. I just finished the translation of postgres. Now, postgresql is 100% in pt_BR. :) This is a big file, so I put it here:

Re: [PATCHES] update for brazilian portuguese translation

2004-01-07 Thread Peter Eisentraut
Euler Taveira de Oliveira wrote: I have updated the brazilian portuguese translation. I just revised libpq, psql, pg_dump, pgscripts, pg_controldata, pg_resetxlog and jdbc. I just finished the translation of postgres. Now, postgresql is 100% in pt_BR. :) Cool! This is a big file, so I put

Re: [PATCHES] add WITH OIDS to CREATE TABLE AS

2004-01-07 Thread Neil Conway
Tom Lane [EMAIL PROTECTED] writes: One thing that is *not* fine is something that I see had snuck past me in the previous WITH OIDS patch. It is not okay for gram.y or scan.l to be looking at GUC variables --- that creates synchronization issues. Good point (I remember reading gram.y's

Re: [PATCHES] add WITH OIDS to CREATE TABLE AS

2004-01-07 Thread Bruce Momjian
Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: Couldn't we use SET only when we need to change the existing value? I'm not sure what you mean. The pg_dump output will look like: -- at the top of the dump SET default_with_oids = false; -- or true, doesn't really matter --

Re: [PATCHES] SIGPIPE handling

2004-01-07 Thread Bruce Momjian
Here is my solution to ignoring SIGPIPE in libpq's send() for threaded apps. It defines a custom SIGPIPE handler if one is not already defined by the application, and uses a thread-local variable that is checked in the SIGPIPE handler to know if the SIGPIPE was caused by a libpq send() call.

Re: [PATCHES] SIGPIPE handling

2004-01-07 Thread Bruce Momjian
One issue I had is in the following function. How can I easily find the current signal value without causing possible signal loss during testing, or possible abort if signals were previously ignored. I could use sigblock, and I think that would exist on a system that doesn't have sigaction, but

[PATCHES] psql error in \? output on \w line

2004-01-07 Thread Zach Irmen
As far as I can tell, the file argument for \w is required; this contradicts what \? says for it (namely that it's optional). A patch follows to fix this if it really is an error and not my misunderstanding. Zach Irmen === RCS file:

Re: [PATCHES] psql \i handling ~ in specified file name

2004-01-07 Thread Bruce Momjian
Peter Eisentraut wrote: Zach Irmen wrote: refers to following item on TODO Have psql '\i ~/tabtab' actually load files it displays from home dir This expansion should also apply to all other commands that take file names. Here is a patch that handles ~ in all the file cases. Thanks

Re: [PATCHES] SIGPIPE handling

2004-01-07 Thread Manfred Spraul
Bruce Momjian wrote: + /* +* We could lose a signal during this test. +* In a multi-threaded application, this might +* be a problem. Do any non-threaded platforms Threaded or non-threaded? +* lack sigaction()? +*/ Additionally, the

[PATCHES] Patch of intarray module in v7.4.1

2004-01-07 Thread Korea PostgreSQL Users' Group
In 7.4.1, intarray module have a problme about equal operator (=). select * from table where intarray_column = '{}'; above query make error. because when not equal operator () is made, this make incorrect equal operator by implicate. so, I patched. Patch content is here. = BEGIN of FILE

Re: [PATCHES] psql \i handling ~ in specified file name

2004-01-07 Thread Zach Irmen
Bruce Momjian wrote: Here is a patch that handles ~ in all the file cases. Beat me to it. :) I do have a few issues that I was trying to sort out myself regarding this, but I guess now is as good a time as any to ask them here. First off, there should be a check after the malloc to make sure