Re: Passing arguments to views

From: Chris Campbell <chris(at)bignerdranch(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tino Wildenhain <tino(at)wildenhain(dot)de>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Passing arguments to views
Date: 2006-02-03 17:56:19
Message-ID: CA8EF2BB-5667-43CE-AD3D-81C073D385CC@bignerdranch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Feb 3, 2006, at 12:27, Tom Lane wrote:

>> I guess I can live without the dependancy tracking. I can always dump
>> and reload my database to re-parse all the functions. Maybe we could
>> have a RELOAD FUNCTION command that would just re-parse an existing
>> function, so I don't have to dump and reload?
>
> Hm? I don't understand why you think this is needed.

Consider function foo() that references table bar. When you CREATE
FUNCTION foo() ... AS 'SELECT ... FROM bar' you get an error message
if bar doesn't exist. If it does exist, CREATE FUNCTION succeeds.

If you later DROP bar, you're not informed that function foo() was
referencing it. You only find that out if you redefine foo() (using
CREATE OR REPLACE FUNCTION and passing in the same definition, which
fails) or if you try to run foo() (and the query fails).

If functions had true dependency tracking, then you couldn't DROP bar
due to foo()'s dependency on it, unless you did a DROP CASCADE and
were alerted that foo() was dropped as well.

I'm fine with those limitations. I can confirm that all of my
functions are not referencing tables that don't exist by doing a
CREATE OR REPLACE FUNCTION to reload each function. A pg_dump/
pg_restore would accomplish this, but it would be nice to have a
"RELOAD FUNCTION" (or "REPARSE"? or "VERIFY"?) command that would
just re-parse the function's source code (like CREATE FUNCTION does)
and spit out errors if the function is referencing relations that
don't exist. Just as a way to confirm that the table modification I
just performed didn't break any functions. On-demand dependency
checking, in a way.

> Note that you can already do
>
> regression=# create function fooey(int, out k1 int, out k2 int)
> returns setof record as
> regression-# $$ select unique1, unique2 from tenk1 where thousand =
> $1 $$ language sql;
> CREATE FUNCTION
> regression=# select * from fooey(44);
> k1 | k2
> ------+------
> 7044 | 562
> 5044 | 692
> 1044 | 789
> 4044 | 1875
> 3044 | 3649
> 2044 | 4063
> 8044 | 6124
> 6044 | 6451
> 9044 | 6503
> 44 | 7059
> (10 rows)
>
> regression=#

Learn something new every day. I'm still using 7.4 for most of my day
job, and I can't do this without supplying a column definition list:

ERROR: a column definition list is required for functions returning
"record"

I hereby withdraw my proposal for "CREATE SQL FUNCTION."

Thanks!

- Chris

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-02-03 18:07:22 Re: Passing arguments to views
Previous Message Chris Campbell 2006-02-03 17:44:00 Re: Multiple logical databases