At 12:51 PM 2/06/2004 +0100, you wrote:

>Hi,
>
>I now have a Dr Watson log with symbols inplace from this crash. I can email
>this to anyone interested - it is about 900K.
>Any help on this issue at all would be greatly appreciated. I realise their
>is alot of room for things to go wrong - but we have been using this
>database for about two years now without problem. It just seems its
>in-capable of creating stored procedures dynamicly - and then using these on
>other connections.

I think you can take that as a "given". Whatever PSQL is, it is NOT a
dynamic scripting language. I've been watching your posts over the past
days and thinking, "No, let someone else give the sermon".

>The documentation does not go into detail as to what
>should and shouldent work. I assumed that if the stored procedure is visible
>to the current transaction it should be OK to call the stored procedure.

That's a queer assumption. An uncommitted stored procedure isn't yet a
stored procedure. Creating (and thereby compiling) a SP is a DDL
operation. Calling it is a DML operation. If you have both of these inside
the same transaction, you're dancing Les Sylphides on freshly-poured
concrete. The engine should throw an exception. It doesn't, and that's a
bug, albeit one of great antiquity.

There are other reasons why compiling SPs and calling them should be
completely discrete...like, the committing of a SP will be deferred in all
cases when any objects it refers to are involved in uncommitted work. If
you're using superserver, the only assumption you can make if you're not
the only user on the system is that your SP isn't going to be available
until after a database shutdown. Same with triggers, same with ref
integrity constraints. The idea of other threads calling it...O, those poor
ballerinas!!

You'll be glad to hear I don't intend to preach further on this. I
probably should have stayed "shut up" on the subject.

/heLen