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
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
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
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
--
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
I am using PHP with postgreSQL and I have been getting a few rare errors
while trying to do selects on a table containing EUC_JP text.
I thought it was a bug with PHP not recognizing a string as invalid
EUC_JP characters and wrote up a bug report but the PHP developers
assure me tha
eport to PHP and pointed this out. Hopefully the developer will see
that this sequence is incorrect EUC-JP and that PHP failed to detect this :)
I *knew* there was nothing wrong with Postgres ;)
Thanks!
Jean-Christian Imbeault
PS I posted to HACKERS a few weeks ago about another bug (a real one
to have been fixed since I
am experiencing the same problem using 7.3.3.
Is there an easy work around?
Thanks,
Jean-Christian Imbeault
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail c
10 matches
Mail list logo
