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 sur
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
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 p
Peter Eisentraut wrote:
> Zach Irmen wrote:
> > refers to following item on TODO
> > Have psql '\i ~/' 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. Tha
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:
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
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.
The
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 matte
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
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 p
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:
http://www.ufgnet.ufg.br/euler/
11 matches
Mail list logo
