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

Re: Functions or Rules and Views?

From: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Postgresql Novice List <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Functions or Rules and Views?
Date: 2003-05-27 09:36:01
Message-ID: 20030527093601.GB3315@campbell-lange.net (view raw or flat)
Thread:
Lists: pgsql-novice
Thanks for the info, Josh.
Looks like I'll be doing most of my work in functions (and triggers)
then. Also it looks like one can make table agnostic functions in some
cases (although there is a penalty because of the need for rebuilding
the query plan for each table/row in this case) which could be useful.

Kind regards,
Rory

On 26/05/03, Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> > I'm embarking on a new project and have been reading up on the new v7.3
> > functions. I have a few general questions about how to use these and
> > whether or not I should use functions exclusively, or also use rules and
> > views.
> 
> I generally use a mix of views, triggers, and data-push functions.
> 
> > Are there any penalties in terms of the speed of execution of a function
> > over a view?
> 
> A SELECT view will generally be much faster than a rowset-returning function, 
> and is usually more easily adapted for partial selects, re-ordering, etc.
> 
> I have not compared the execution speed of updatable views + rules vs. 
> data-push functions, as I use the latter almost exclusively since they allow 
> me to bundle security and rights checking, and custom error messages, into 
> the same function, something which is more cumbersome with updatable views.

-- 
Rory Campbell-Lange 
<rory(at)campbell-lange(dot)net>
<www.campbell-lange.net>

In response to

pgsql-novice by date

Next:From: papapepDate: 2003-05-27 10:50:10
Subject: Re: Inserting data of two other tables [Now deleting ...]
Previous:From: Dani OderbolzDate: 2003-05-27 08:09:19
Subject: Re: add foreign key constraint after table creation?

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