| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | YourSoft <yoursoft(at)freemail(dot)hu>, pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: JDBC driver bug? |
| Date: | 2007-03-05 16:05:04 |
| Message-ID: | 19018.1173110704@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> YourSoft wrote:
>> When you call a pgsql stored procedure (with PreparedStatement), that
>> calls an other stored procedure, and you recall the stored procedure
>> after dropping and recreating second stored procedure, the calling will
>> throw an exception with:
> That's a known issue. The first time you call the procedure, it's
> compiled and cached. The second time you call it, the cached plan is no
> longer valid because the function it depends on has been dropped and
> recreated.
> The good news is that Tom Lane has added support for plan invalidation
> for 8.3 branch, so this should be fixed in the next major release.
This behavior will not change in 8.3, because I have no intention of
including function invalidation in the patch. The correct answer is
"don't do that --- use CREATE OR REPLACE FUNCTION instead".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Cramer | 2007-03-05 16:10:07 | Re: Utilizing executeBatch() with stored procedures |
| Previous Message | Danny Schueler | 2007-03-05 15:44:26 | jdbc integer value oid to big! |