Sorry if this has been brought up before. I tried searching the archives
at http://archives.postgresql.org/pgsql-bugs/ but it seems the search
function is broke.
Don't know if this is a bug or not but ... this query worked under 7.2.1
but doesn't under 7.3RC2. datetime was a built-in function i
Seems to be a bug in the bin/createdb script. I tried to use the script
as is and got the following error:
$ createlang plpgsql JC
ERROR: stat failed on file '$libdir/plpgsql': No such file or directory
createlang: language installation failed
But my PGLIB path is correct:
$ set | grep PG
PGDA
I seem to be having some regression problems w/ freebsd for both rc1 and
rc2.
They are the old 0 / -0 problems. I've attached the regression diff.
$uname -an
FreeBSD farcaster 4.7-RELEASE FreeBSD 4.7-RELEASE #1: Sat Nov 16 21:55:12
EST 2002 root@farcaster:/usr/src/sys/compile/FARCASTER i386
bo
Don't know if this is a bug or not but ... this query worked under 7.2.1
but doesn't under 7.3RC2. datetime was a built-in function ...
$ psql JC -c "select to_char(datetime(upload_time),'-MM-DD') as
utime from products where id='989000627108' "
ERROR: Function datetime(timestamp without ti
On Tuesday 26 November 2002 16:43, Rod Taylor wrote:
> On Fri, 2002-11-22 at 15:51, Stefanos Harhalakis wrote:
> > I'm running postgresql 7.2.1 on linux.
> >
> > I cannot run vacuumm on a table in a database i'm running for about 7
> > months. I get:
> >
> > ERROR: No one parent tuple was found
>
Yup.. 4.0 - 4.5 have positive zeros.
4.6 has negative zeros
4.7 release has positive zeros but shortly after -stable has negative
zeros.
It's difficult to differentiate between 4.7-release and 4.7-stable, so
the regression tests were made for -stable.
On Tue, 2002-11-26 at 15:59, bpalmer wrot
[SuSE Linux 8.0, Postgresql-7.3rc2, gcc-3.2, python 2.2.1]
[using PyGresql v3.3 from the 7.3rc2 distribution]
Postgres install goes fine as a fresh install. Psql access is fine.
Pgdb (the python interface) cursor.execute fails on any query; it asks for
"pg_type.typprtlen",
which has apparently b
Jean-Christian Imbeault <[EMAIL PROTECTED]> writes:
> Don't know if this is a bug or not but ... this query worked under 7.2.1
> but doesn't under 7.3RC2. datetime was a built-in function in 7.2.1 but
> seems to be "missing" from 7.3RC2 ...
> $ psql JC -c "select to_char(datetime(upload_time),'Y
Jean-Christian Imbeault <[EMAIL PROTECTED]> writes:
> I editing bin/createdb, hard coding the value of PGLIB and createdb then
> worked fine.
This is certainly not the correct solution.
regards, tom lane
---(end of broadcast)--
Tom Lane wrote:
I editing bin/createdb, hard coding the value of PGLIB and createdb then
worked fine.
This is certainly not the correct solution.
I certainly agree. What can I do to pin-point the root cause of the
problem? My environment vars seem to be set correctly so I don't
understand
Jean-Christian Imbeault <[EMAIL PROTECTED]> writes:
>> This is certainly not the correct solution.
> I certainly agree. What can I do to pin-point the root cause of the
> problem? My environment vars seem to be set correctly so I don't
> understand why the createlang script is not picking them u
Tom Lane wrote:
>
> I'm still wondering if you are actually invoking a 7.3 server, and not
> an old pre-7.1 one. 'psql -c "select version()"' would tell the tale.
[postgres@localhost work]$ psql JC -c "select version()"
version
--
Hi!
Reading the archives I understand this is a problem of postgres version
prior 7.1, and I'm experiencing the very same error as Steve Riley
reported last month. I saw that the suggestion was to use 7.2, but I'm
not sure you meant dump 7.1 database from 7.1 backend using 7.2 pg_dump.
We have ap
As a follow-up I get an error when dropping plpgsql and then trying to
re-create it ...
$ psql JC -c "drop language plpgsql cascade"
NOTICE: Drop cascades to function cancell_all_li()
NOTICE: Drop cascades to trigger insert_invoices on table invoices
NOTICE: Drop cascades to function update_in
You must have been right about the problem being due to something being
leftover from the old DB because I cannot recreate the problem anymore.
Sorry to have spotted a non-existent bug.
Jc
---(end of broadcast)---
TIP 3: if posting/reading throug
Jean-Christian Imbeault <[EMAIL PROTECTED]> writes:
> As a follow-up I get an error when dropping plpgsql and then trying to
> re-create it ...
> $ psql JC -c "drop language plpgsql cascade"
> NOTICE: Drop cascades to function cancell_all_li()
> NOTICE: Drop cascades to trigger insert_invoices
I said:
> DROP LANGUAGE only drops the pg_language entry, not the call handler.
> I think the dropdb script would drop the handler too, but you didn't
> do that.
s/dropdb/droplang/, of course. Sorry.
regards, tom lane
---(end of broadcast)---
Jean-Christian Imbeault writes:
> But my PGLIB path is correct:
PGLIB doesn't do anything.
At all.
Really.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
su
18 matches
Mail list logo
