Re: Was: Triggers, Stored Procedures, PHP - Mailing list pgsql-general

From Doug McNaught
Subject Re: Was: Triggers, Stored Procedures, PHP
Date
Msg-id 87wu9i4uk4.fsf@asmodeus.mcnaught.org
Whole thread Raw
In response to Was: Triggers, Stored Procedures, PHP  (Shane D <shane.dawalt@wright.edu>)
Responses Re: Was: Triggers, Stored Procedures, PHP
List pgsql-general
Shane D <shane.dawalt@wright.edu> writes:

>    Could someone explain to me the usefulness of views?  I understand
> how they are created.  I understand a single query can be created as a
> view returning all records in a single column of a single table, or
> maybe even multiple columns across many tables using a complex join.
>
>    That sounds find if all you want to do is to populate your
> drop-down list box with selection choices or use the same search
> criteria each time.  But if I want to access certain information for a
> particular customer that requires joins and the like, then a view
> would be great. But as far as I know, I am unable to place search
> parameters into a view.  Is this false or am I totally missing the
> point of views?

It's false.  You can treat a view just like a table and add clauses to
your query that restrict it beyond what the view gives you.  I think
that's what you're asking about...

Views are useful for things like:

1) Insulating apps from details of the schema which may change
2) Giving different users different, well, views of the data, perhaps
   on a column basis.  Create a view that only shows a subset of
   columns, and only allow unprivileged users access to the view, not
   the underlying table(s).

-Doug

pgsql-general by date:

Previous
From: Shane D
Date:
Subject: Was: Triggers, Stored Procedures, PHP
Next
From: Peter Eisentraut
Date:
Subject: Re: Drop Cascade of Domains