Re: Patch: plan invalidation vs stored procedures

From: Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: plan invalidation vs stored procedures
Date: 2008-08-07 08:10:22
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> > Changing statement result type is also currently prohibited in
> > StorePreparedStatement. There maybe good reasons for this,
> How about "the SQL spec says so"?

Prepare time is often also the time when you bind the result, or more
generally set up the code to handle the result.

Generally I argue, that a mode of operation must exist where a change in
return type throws an error, so the client can readjust to the change.

We are only allowed to silently replan when it is clear that
the caller is agnostic to the change.
e.g. because the caller only accesses explicit columns of the return type/result set,
or does not supply a new parameter with a default, (or because he set some
parameter that tells us he can cope).

Certainly a new prepare must be able to cope with the change though,
which currently does not seem to be the case when an SP calls another
one that was dropped (and recreated)?


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-08-07 09:20:22 Re: Parsing of pg_hba.conf and authentication inconsistencies
Previous Message Abhijit Menon-Sen 2008-08-07 08:08:03 [PATCH] allow has_table_privilege(..., 'usage') on sequences