I've had this also. The problem has always been that I've made a mistake in my
SQL.
Since the transaction is going to rollback anyway, any subsequent changes are
ignored.
I've done 95,000 inserts in a transaction without problems.
Regards
John
- Original Message -
From: Matthias Teege <
Hello
I have RH6.2 with pg 6.5, which I wish to upgrade to 7.02
I installed the RPMS but then psql would not work. I gave a weird linker error.
Then I tried to compile the SRPM.
This fails with an Undefined symbol F_OIDEC
in istrat.c line 494.
Does anyone have a solution for this?
Regards
You just haven't met the right application yet.
in the manual there is a discussion on other methods that were previosly
used.
The PG system is good, with minor limitations in the lo* API.
I'm busy writing a faxserver application where all the fax page data is
stored as a blob.
Its just so e
-Original Message-
From: Howie <[EMAIL PROTECTED]>
To: John Huttley <[EMAIL PROTECTED]>
>
>the one thing i miss is the ability to determine a lo's size (
>hinthintnudgenudgewinkwink ).
Here's a snippet of code
lo_lseek(cntl.conn, lo_fax,0, SEEK_EN
> I believe we are adding Oracle compatibility as possible. We are
> working on write-ahead log, long tuples, foreign keys, and outer joins.
> Anything else?
Yes, earlier in the year I was trying to migrate from Pervasive SQL to
posgtres and
came to a screaming halt when it wouldn't do a large v
Ed, There is big difference between PG's functions and Stored Procedures,
as they are commonly used.
PG's functions return a single value, Stored Procedures return a record set.
This will require some substantial changes to things like pg_tables, to
support what are effectively
'virtual tables'.
Quite a few people (including me) have had problems with creating triggers.
Last week Jan gave us the definative answer.
No,
trigger procedures in Postgres are allways defined to take no
arguments and have a return type "opaque".
The main error above is, that the "sql" language c
