Re: Outstanding patches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Outstanding patches
Date: 2001-05-08 22:08:07
Message-ID: 8733.989359687@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> But don't we already have problems with changing functions that use
> tables or does this open a new type of problem?

But this feature isn't about functions that use tables internally;
it's about tying the fundamental signature of the function to a table.
I doubt that that's a good idea. It definitely does introduce potential
for problems that weren't there before, per the illustrations I already
gave.

You commented earlier that it's easy to "change the width of a column"
with this approach, but that's irrelevant, because atttypmod is not part
of a function's signature anyhow.

> If we define things as %TYPE in plpgsql, do we handle cases when the
> column type changes?

Sort of, because we just need to drop the cached precompiled version of
the function --- you can do that by starting a fresh backend if nothing
else, and we have speculated about making it happen automatically.
Changing a function's signature automatically is a MUCH bigger and
nastier can of worms, because it affects things outside the function.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Poole 2001-05-08 22:15:53 Re: Re: Outstanding patches
Previous Message Bruce Momjian 2001-05-08 21:55:54 Re: Outstanding patches

Browse pgsql-jdbc by date

  From Date Subject
Next Message Richard Poole 2001-05-08 22:15:53 Re: Re: Outstanding patches
Previous Message Jeff Duffy 2001-05-08 22:05:16 Re: Why?? executeQuery() & exception: "No results were returnedby the query."