Skip site navigation (1) Skip section navigation (2)

Re: Passing arguments to views

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Campbell <chris(at)bignerdranch(dot)com>
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 16:21:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Chris Campbell <chris(at)bignerdranch(dot)com> writes:
> I want to beef up rules versus beefing up functions.

Martijn didn't present a very convincing argument why this is a bad
idea, but I agree with him that it is.  The problem to me is that a
"view with arguments" is fundamentally wrong --- a view is a virtual
table and there is no such thing as a table with arguments.  The whole
notion distorts the relational data model beyond recognition.

The SRF concept captures what you want a whole lot better.  If the
implementation isn't up to snuff, we should improve it, not warp other
pieces of the system.

Martijn mentioned the idea of inlining SQL functions that return sets
--- this is something I've toyed with too, but not got round to looking
at seriously.  AFAICS it would accomplish everything that you could do
with parameters in ON SELECT rules, considering the existing
restrictions on what can be in an ON SELECT rule.  And it wouldn't
require any new concepts at all, just a few(?) pages of code.

As for the dependency issue, one man's bug is another man's feature.
I think the fact that we don't track the internal dependencies of
functions is not all bad.  We've certainly seen plenty of complaints
about how you can't easily change tables that a view is depending on
because the view dependencies block it...

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Chris CampbellDate: 2006-02-03 16:38:14
Subject: Re: Passing arguments to views
Previous:From: Chris BrowneDate: 2006-02-03 16:09:39
Subject: Re: Multiple logical databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group