Tony wrote:
> I already had in the first post I replied to, but at the risk of
> sounding redundant, I'll say it again.
>
> Views: When I came to PG I didn't know what they were, saw no point
> to them (still don't) why do you need a function to provide details of
> a query when a more complicated query gives the same data? Are they
> designed for people who don't like to type long queries?
Personally I find views useful because I can hide the details of the
database internals from the application. Hence they provide an
"interface" level abstraction. This is very important if you want to
isolate the database and application development.
I've never seen that stated in a document.
> Stored Procedures: Sounds good in principle, but in what ways can I
> benefit most (I understand this now) at the time of moving to PG, I
> couldn't see the difference between writing my code in an a Stored
> Proc or an API.
I don't understand what you mean here/
>
>
> This isn't definitive list but more of a flavour of the obstacles I
> hit when I first met PG. If I hadn't persevered (and many may not)
> I'd have ended up with a PG server full of DBs designed and built as
> if they were on a MySQL server.
Yep - I see that alot.