> > There are (at least) two distinct problems involved here. One is
> > getting plpgsql to deal correctly with rowtypes that include dropped
> > columns. The other is getting it to react when someone alters a table
> > whose rowtype is relied on by already-compiled functions.
I'm working on thi
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Taking it a bit further...
>
> There are (at least) two distinct problems involved here. One is
> getting plpgsql to deal correctly with rowtypes that include dropped
> columns. The other is getting it to react when someone alters a ta
Joe Conway <[EMAIL PROTECTED]> writes:
> Taking it a bit further...
There are (at least) two distinct problems involved here. One is
getting plpgsql to deal correctly with rowtypes that include dropped
columns. The other is getting it to react when someone alters a table
whose rowtype is relied
Christopher Kings-Lynne wrote:
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing, but
Christopher Kings-Lynne wrote:
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing, but
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing, but I need a demonstrated
example
