> > Don Sceifers wrote:
> > > My company is fairly new at Postgresql, but we have hit a problem,
where
> > > we modify a table using ALTER, and our stored procedures stop working.
We
> > > have a grasp as to why this happens, but I was wondering if this v7.4
> > > upgrade fixes this issue?
Not sure if this applies with Postgres but did you also recompile the stored
procedures? If I remember correctly Sybase and Informix (?) required store
procedured to be recompiled after DDL to tables they used, and Oracle often
invalidates any functions, views, packages and procedures if they have any
relation to the modified table.
----- Original Message -----
From: "Robert Treat" <xzilla@users.sourceforge.net>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: <pgsql-hackers@postgresql.org>
Sent: Thursday, November 20, 2003 7:52 AM
Subject: Re: [HACKERS] question about fixes in v7.4...
> On Wed, 2003-11-19 at 22:50, Bruce Momjian wrote:
> > Don Sceifers wrote:
> > > My company is fairly new at Postgresql, but we have hit a problem,
where
> > > we modify a table using ALTER, and our stored procedures stop working.
We
> > > have a grasp as to why this happens, but I was wondering if this v7.4
> > > upgrade fixes this issue?
> >
> > This is a known issue. There is no way for us to know what stored
> > tables/columns you are using in your function. You might find that
> > reconnecting to the database after the ALTER will fix the problem. We
> > do cache function code, so reconnecting will erase that cache.
> >
>
> Would it be worth putting in a partial implementation? I'm thinking
> specifically about functions that return table types. Could they be
> hooked up with dependency information and made to complain?
>
> Robert Treat
> --
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
