Laszlo Kohl ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
The ignored "_" character
Long Description
Hi,
I am Laszlo from Hungary.
I have some problem with PostgreSQL.
Environment:
PostgreSQL version: 7.0.3
Server OS: RedH
On Mon, May 07, 2001 at 03:01:28AM -0400, [EMAIL PROTECTED] wrote:
> Laszlo Kohl ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> The ignored "_" character
>
> Long Description
> Hi,
>
> I am Laszlo from Hungary.
> I h
INSERT INTO "ObjectLog1" VALUES (1, '2001-05-02 13:48:59.999', 0, 10, 1, 1,
9, 0, 0, 0, 0);
djs=# select "Date" from "ObjectLog1";
Date
---
2001-05-02 13:48:60.00+03
(1 row)
--->13:48:60.00 !!
It supposed to be 13:49:00.00
Also this bug l
djs=# SELECT version();
version
---
PostgreSQL 7.1 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)
INSERT INTO "ObjectLog1" VALUES (1, '2001-05-02 13:48:59.999', 0, 10, 1, 1,
9, 0, 0, 0, 0);
djs=# select "Da
Your name : Gabor Z. Papp
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium Celeron
Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.4 ELF
PostgreSQL version (example
Evidently you're using the newly-released readline 4.2.
Update to PG 7.1.1, or downgrade to readline 4.1.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(
I just checked out CVS this morning the REL7_1_STABLE branch. I
configured it with:
./configure --enable-debug
and ran the regression test fine on OpenBSD 2.8 (AMD processor) (The
same problem has been reproduced by someone else on RH6.2)
I then proceed to load the OpenACS datamodel and
On Mon, May 07, 2001 at 05:14:48PM -0500, Robert Hentosh wrote:
:: snip ::
> I can send the datamodel and core file if needed. I loaded GDB with the
> core file and got the following:
I just put the datamodel at http://www.io.com/~hentosh/sql.tar.gz
---(end of broadcas
Robert Hentosh <[EMAIL PROTECTED]> writes:
> I then proceed to load the OpenACS datamodel and had the backend crash.
> This datamodel loads fine on 7.1.
Ugh.
> I can send the datamodel and core file if needed.
Datamodel please, corefile no.
regards, tom lane
--
Robert Hentosh <[EMAIL PROTECTED]> writes:
> I then proceed to load the OpenACS datamodel and had the backend crash.
> This datamodel loads fine on 7.1.
Sigh. Looks like I managed to break plpgsql's handling of SELECT with
no data found. Mea maxima culpa (though the regression tests perhaps
des
elein ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
interval( 'seconds 27960' ) is broken
Long Description
In 7.0.3, I'm converting seconds from midnight to a time of
day using interval ( 'seconds '). This worked fine in
7.
Robert Hentosh <[EMAIL PROTECTED]> writes:
> I just put the datamodel at http://www.io.com/~hentosh/sql.tar.gz
Hm. I notice that postgres.sql hardwires the location of the plpgsql
handler:
create function plpgsql_call_handler() RETURNS opaque
as '/usr/local/pgsql/lib/plpgsql.so' language 'c';
On Mon, May 07, 2001 at 08:28:33PM -0400, Tom Lane wrote:
> Robert Hentosh <[EMAIL PROTECTED]> writes:
> > I just put the datamodel at http://www.io.com/~hentosh/sql.tar.gz
>
> Hm. I notice that postgres.sql hardwires the location of the plpgsql
> handler:
>
> create function plpgsql_call_handl
Tom Lane wrote:
>
> Robert Hentosh <[EMAIL PROTECTED]> writes:
> > I then proceed to load the OpenACS datamodel and had the backend crash.
> > This datamodel loads fine on 7.1.
>
> Ugh.
>
There was a bug report in Japan that plpgsql
crashes if select returns no row. This seems
a bug introduced
[EMAIL PROTECTED] writes:
> In 7.0.3, I'm converting seconds from midnight to a time of
> day using interval ( 'seconds '). This worked fine in
> 7.0.3 and gives a Bad interval external representation message
> in 7.1.
This has never been the intended or documented format; it should
be ' second
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> There was a bug report in Japan that plpgsql
> crashes if select returns no row. This seems
> a bug introduced by your latest change on
> pl_exec.c.
Indeed. Too bad that report didn't arrive on Friday.
I am mightily embarrassed :-(
Robert Hentosh <[EMAIL PROTECTED]> writes:
>> If this were to suck in a wrong-version copy of plpgsql.so (and yes,
>> I think 7.1 vs 7.1.1 could be wrong version) then that could cause
>> failures.
> I played with this a little. What would be the proper solution?
At the moment, the solution is
> ... (though the regression tests perhaps
> deserve a share of the blame too, for not covering that case).
> Patch to appear shortly...
Will the patch include a case for the regression test? Or could someone
(other than me??!!) volunteer to cover that?
- Thomas
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Will the patch include a case for the regression test? Or could someone
> (other than me??!!) volunteer to cover that?
Seems like a good idea. As the embarrassee, I'm perhaps too close
to the problem to write a good addition to the regress tests; any
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I had a pltcl issue here yesterday. I fixed the problem, but I noted
> that pltcl is linked not using information from Makefile.shlib, but
> using commands from tclConfig.sh. Not sure this is wrong, but it
> certainly can cause problems if tclConfig.sh
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Looking at the plpgsql code, it's clear that what's actually implemented
>> is
>> RAISE level string-literal [ , variable [ , variable [ ... ] ]
> I see the current docs showing:
> RAISE level 'format' [, identifier [...]];
> Is this acceptable
I wrote:
>> Probably. And 'format' is even more misleading, since it implies that
>> you write a printf-like format string, which you do not. The output is
>> just the concatenation of the literal and the variable values.
Ugh. Should've read the code before pontificating ;-). The code makes
c
22 matches
Mail list logo