The following bug has been logged online:
Bug reference: 2146
Logged by: Chuck Wegrzyn
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: Linux
Description:ECPG, cursros and conditional compilations...
Details:
I don't know if this is known
The following bug has been logged online:
Bug reference: 2153
Logged by: Norman Young
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Solaris
Description:atan2(0, 0) ERROR: input is out of range on Solaris
Details:
Solaris
===
$ un
Tom Lane wrote:
> Works for me:
>
> regression=# create domain dint as int not null;
> CREATE DOMAIN
> regression=# create table t1 (f1 dint);
> CREATE TABLE
> regression=# create view v1 as select * from t1;
> CREATE VIEW
> regression=# create rule r1 as on insert to v1 do instead
> regression-#
The following bug has been logged online:
Bug reference: 2150
Logged by: Aaron Swartz
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Mac OS X
Description:PL/Python function delcared STABLE gets run repeatedly
Details:
We have the PL/Pyt
The following bug has been logged online:
Bug reference: 2154
Logged by: Glauco Carlos Silva
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Windows XP
Description:conversion problem
Details:
the result of function (select lower('ÃÃÃÃ
The following bug has been logged online:
Bug reference: 2149
Logged by: Abigail Corrigan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: linux
Description:can not enter µM into a varchar field in version 8.1.1
Details:
I get an error w
The following bug has been logged online:
Bug reference: 2151
Logged by: Kerim Simsek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1 Windows
Operating system: Windows 2000 Pro
Description:ODBC, Large Object, Visual Basic, GetChunk
Details:
Large object Tab
The following bug has been logged online:
Bug reference: 2152
Logged by: Andreas Kretschmer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: Debian/Linux
Description:psql crash reproducible
Details:
i wrote a wrong query, and psql crash:
The following bug has been logged online:
Bug reference: 2148
Logged by: Sokolov Yura
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Slackware Linux 2.6.14.1
Description:Crashes on simple statement
Details:
select ms from (select 1) ms
-
"Norman Young" <[EMAIL PROTECTED]> writes:
> Description:atan2(0, 0) ERROR: input is out of range on Solaris
Actually, I'd argue that it's the Linux atan2() that's broken. But
in any case, what you're looking at is a difference in the behavior
of the underlying library functions on the t
"Aaron Swartz" <[EMAIL PROTECTED]> writes:
> We have the PL/Python function get_foo(n) that returns an array. If this
> function is declared IMMUTABLE, then:
> SELECT * FROM tablenamehere WHERE id = any(get_foo(21));
> returns quickly. If the function is declared STABLE, however, PostgreSQL
> seems
"Andreas Kretschmer" <[EMAIL PROTECTED]> writes:
> test=# select x from (select extract(dow from ('2006/01/01'::date +
> (generate_series(0,10)||'days')::interval)::date)) x;
> server closed the connection unexpectedly
Works for me as of 8.1 branch tip, so the fix is in either 8.1.1 or
8.1.2.
On Fri, Jan 06, 2006 at 10:30:28AM -0600, Jim C. Nasby wrote:
> OS X, Version 8.1.1:
> decibel=# select ms from (select 1) ms;
> server closed the connection unexpectedly
This query doesn't crash for me with the latest CVS. It might be
the same problem Tom fixed a few weeks ago:
http://archives.
"Sokolov Yura" <[EMAIL PROTECTED]> writes:
> select ms from (select 1) ms
Works for me ... try a more recent 8.0.* release.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore you
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Andreas Kretschmer" <[EMAIL PROTECTED]> writes:
> > test=# select x from (select extract(dow from ('2006/01/01'::date +
> > (generate_series(0,10)||'days')::interval)::date)) x;
> > server closed the connection unexpectedly
>
> Works for me as of 8.
Aaron Swartz <[EMAIL PROTECTED]> writes:
> The function we're running returns an array, and it is non-trivial to
> compute. We do a simple query with it like "SELECT * FROM
> tablename WHERE id = any(foo(21))").
> When the function is STABLE (or VOLATILE) the function is run
> to generate the arra
mordicus <[EMAIL PROTECTED]> writes:
> Le Vendredi 6 Janvier 2006 16:31, Tom Lane a écrit :
>>> ./configure --enable-thread-safety
>>> conftest.c:140:44: error: ./src/tools/thread/thread_test.c: No such file
>>> or directory
>>
>> Hmm, it works fine for me. Is that file actually present in your s
On Thu, Jan 05, 2006 at 04:19:23PM +, Sokolov Yura wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2148
> Logged by: Sokolov Yura
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0
> Operating system: Slackware Linux 2.6.14.1
> Descriptio
On Fri, Jan 06, 2006 at 12:43:06PM -0500, Tom Lane wrote:
> Oh, you are misunderstanding the point of IMMUTABLE/STABLE.
> STABLE essentially gives the planner permission to use the function
> in an indexscan qualification. It does *not* cause any caching of
> the function result in other contexts,
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Is caching of results for STABLE/IMMUTABLE functions called with a
> constant something that would be reasonable to add?
I tend to think not: the distributed overhead would outweigh the
advantages. See previous discussions in the archives.
(However, t
On Fri, Jan 06, 2006 at 02:48:59PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Is caching of results for STABLE/IMMUTABLE functions called with a
> > constant something that would be reasonable to add?
>
> I tend to think not: the distributed overhead would outweigh the
"John Supplee" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Works for me:
> You need to modify your test case slightly.
OK, got it. Patch for 8.1 is attached if you need it. Thanks for the
test case.
regards, tom lane
Index: rewriteManip.c
22 matches
Mail list logo