Serguei Mokhov writes:
> Attached is the updated pg_dump (fixed c-string and a fuzzy msg) and
> libpq (3 new messages) translations.
> Just in case I attach pg_controldata and pg_resetxlog, since you
> have installed the old ones.
OK, I have installled the four files that were attached to this m
Guillaume LELARGE writes:
> Here are three 7.4cvs-updated french po files.
Installed.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/
Joe Conway <[EMAIL PROTECTED]> writes:
> Note that I also changed behavior in that when trigdata->tg_event
> doesn't match anything known -- instead of pressing on with a value of
> "UNKNOWN" it now throws an "elog(ERROR...". The previous behavior made
> no sense to me, but you may not want to c
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Note that I also changed behavior in that when trigdata->tg_event
doesn't match anything known -- instead of pressing on with a value of
"UNKNOWN" it now throws an "elog(ERROR...". The previous behavior made
no sense to me, but you may not
Joe Conway <[EMAIL PROTECTED]> writes:
> This patch includes pltcl and plpython, with the mentioned style issue
> fixed. Both PLs pass their scripted tests and my simple statement level
> trigger test.
Applied, thanks.
BTW, one other stylistic nit: I don't think comments like
/
Tom Lane wrote:
BTW, one other stylistic nit: I don't think comments like
/* internal error */
elog(ERROR, "unrecognized OP tg_event: %u", tdata->tg_event);
are really necessary. In the brave new ereport world, any elog(ERROR)
call is an internal error by definitio
Hi, we recently were using the libpq++ interface to postgres in a
program that had many filehandles open. We of course ran into the bug
with select() where filehandles above 1024 cause serious problems.
I fixed the bug by replacing select() with poll() in libpq/fe-misc.c.
I was going to file a bug
On Sat, 02 Aug 2003 18:43:23 +0200, Dag-Erling Smørgrav wrote:
> It works by defining a new
> column constraint (CONSTR_AUTO_INCREMENT) which is handled specially
> by transformColumnDefinition() - after it has transformed SERIAL
> pseudo-types to the corresponding INT types
Beware that MySQL's A
Anne Dudfield <[EMAIL PROTECTED]> writes:
> I was going to file a bug, but I saw that this problem had already
> been fixed in CVS. Unfortunately, it does not appear to be fixed in
> the latest postgres version (7.3.4). When will you release a patch
> with this fix in it?
7.4. We are not going to
