On Thu, Jan 27, 2005 at 08:11:50PM -0300, Alvaro Herrera wrote:
> On Thu, Jan 27, 2005 at 04:01:32PM -0700, Michael Fuhr wrote:
> >
> > What do you have in mind? What would OLD and NEW refer to in
> > statements that affect multiple rows? Are you thinking of a way
> > to refer to all of the old
On Thu, Jan 27, 2005 at 04:01:32PM -0700, Michael Fuhr wrote:
> On Thu, Jan 27, 2005 at 07:46:54PM -0300, Alvaro Herrera wrote:
> > On Thu, Jan 27, 2005 at 03:34:55PM -0700, Michael Fuhr wrote:
> >
> > > OLD and NEW don't make sense in statement-level triggers because
> > > the statement could aff
On Thu, Jan 27, 2005 at 07:46:54PM -0300, Alvaro Herrera wrote:
> On Thu, Jan 27, 2005 at 03:34:55PM -0700, Michael Fuhr wrote:
>
> > OLD and NEW don't make sense in statement-level triggers because
> > the statement could affect many rows. Use FOR EACH ROW if you need
> > to access the row value
On Thu, Jan 27, 2005 at 03:34:55PM -0700, Michael Fuhr wrote:
> OLD and NEW don't make sense in statement-level triggers because
> the statement could affect many rows. Use FOR EACH ROW if you need
> to access the row values.
IMHO they do make sense. It's just that they haven't been implemented
On Thu, Jan 27, 2005 at 05:11:16PM -0500, Tamas Vincze wrote:
> But I guess my only option now is to upgrade my build tools and give
> it another try...
Even if that works, it might be useful to track down exactly what's
causing the problem.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
On Thu, Jan 27, 2005 at 03:13:27PM -0700, Lee Jensen wrote:
> I have postgres 7.4.6 installed on 2 machines one debian and one
> freebsd. Both are the most recent installs of each OS. On both I have
> the plpython module and both are having the same issue. Essentially when
> a function is called
On Thu, Jan 27, 2005 at 03:13:27PM -0700, Lee Jensen wrote:
> I have postgres 7.4.6 installed on 2 machines one debian and one
> freebsd. Both are the most recent installs of each OS. On both I have
> the plpython module and both are having the same issue. Essentially when
> a function is calle
On Thu, Jan 27, 2005 at 02:33:05PM -0700, Michael Fuhr wrote:
>
> A few months ago an issue with strtod() on Solaris came up:
>
> http://archives.postgresql.org/pgsql-bugs/2004-08/msg00073.php
> http://archives.postgresql.org/pgsql-bugs/2004-08/msg00127.php
>
> I wonder if you're experiencing a
I have postgres 7.4.6 installed on 2 machines one debian and one
freebsd. Both are the most recent installs of each OS. On both I have
the plpython module and both are having the same issue. Essentially when
a function is called from a trigger the TD tuple get's populated with
all the standard
Michael Fuhr wrote:
Is anything else under there?
I re-built it with
$ ./configure --prefix=/usr/local/pgsql-8.0.0 --without-readline
and still have the same errors in the float4, float8 and misc tests.
ldd src/test/regress/tmp_check/install/usr/local/pgsql-8.0.0/bin/postmaster
libz.so =>
On Thu, Jan 27, 2005 at 12:59:06PM -0700, Michael Fuhr wrote:
> When I get a chance I'll do a build with --enable-thread-safety
> and without --enable-debug and see if it matters.
It occurred to me that --enable-thread-safety affects the client-side
libraries so I don't know why that would matter
I am trying to restore a dump from 7.4.1 to 8.0.
I am using the pg_dump in 8.0 to dump the database. I am getting the
following error message.
I looked up the pg_database table in 8.0 and there is no column named
datpath it is in 7.4.1. When I am using the pg_restore in 8.0 shouldn't
it be knowin
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Jan 27, 2005 at 02:08:36PM -0500, Tamas Vincze wrote:
>> I've compiled from the final tarball - maybe something's changed
>> since you got the sources from CVS?
> I've been following the 8.0 development for months, doing CVS updates
> and rebuildi
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Hmmm...the PostgreSQL binaries on my Solaris/sparc box are 32-bit
> and the FreeBSD box is a 32-bit i386, yet both are susceptible to
> the crash.
On looking at it, the problem is that the functions are defined in such
a way that you can pass any random i
On Thu, Jan 27, 2005 at 02:08:36PM -0500, Tamas Vincze wrote:
> The configure command was:
> $ ./configure --prefix=/usr/local/pgsql-8.0.0 --enable-thread-safety
> --with-includes=/export/home/vincze/include
> --with-libs=/export/home/vincze/lib
>
> The readline library is installed under my ho
On Thu, Jan 27, 2005 at 02:22:36PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > On Thu, Jan 27, 2005 at 05:26:26PM +0100, PFC wrote:
> >> It seems that contrib/intagg crashes my server :
>
> > I see the same thing with PostgreSQL 8.0.0 (REL8_0_STABLE) on Solaris 9
> > and
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Jan 27, 2005 at 05:26:26PM +0100, PFC wrote:
>> It seems that contrib/intagg crashes my server :
> I see the same thing with PostgreSQL 8.0.0 (REL8_0_STABLE) on Solaris 9
> and FreeBSD 4.11.
The intagg source code says
NOTE: This module requ
Tom,
> How so? If you think that the timestamp-without-zone is relative to GMT
> rather than your local zone, you say something like
> extract(epoch from (timestampvar AT TIME ZONE 'GMT'))
Ah, that didn't seem to work before. I must have done the parens wrong.
> Quite honestly, you shoul
Hi Michael,
I see test failures in float4, float8 and misc.
What configure options did you use? What compiler are you using?
Did you specify any custom compiler or linker options?
The configure command was:
$ ./configure --prefix=/usr/local/pgsql-8.0.0 --enable-thread-safety
--with-includes=/expo
Josh Berkus writes:
> The problem with the current functionality is that it makes it impossible to
> get a GMT Unix timestamp out of a TIMESTAMP WITHOUT TIME ZONE without string
> manipulation.
How so? If you think that the timestamp-without-zone is relative to GMT
rather than your local zone,
[I've Cc'ed pgsql-bugs and set the Reply-To header to that list.]
On Thu, Jan 27, 2005 at 05:26:26PM +0100, PFC wrote:
>
> It seems that contrib/intagg crashes my server :
> -
> select int_agg_final_array(1);
> server c
On Thu, Jan 27, 2005 at 11:06:54AM -0500, Tamas Vincze wrote:
> I see test failures in float4, float8 and misc.
What configure options did you use? What compiler are you using?
Did you specify any custom compiler or linker options?
I've built PostgreSQL 8.0.0 (from CVS) on Solaris 9/sparc many
Tom,
> I don't believe there is anything wrong here. extract(epoch) is defined
> to produce the equivalent Unix timestamp, and that's what it's doing.
> See the thread at
> http://archives.postgresql.org/pgsql-bugs/2003-02/msg00069.php
Darn. I missed that discussion, I'd have argued with Thomas
Hi,
I see test failures in float4, float8 and misc.
Both float4 and float8 fail on the tests involving NaN and Infinity.
Here's the verbose output of the failed statements:
template1=# SELECT 'NaN'::float4;
ERROR: 22003: type "real" value out of range: overflow
LOCATION: CheckFloat4Val, float.c:2
24 matches
Mail list logo
