PostgreSQL does support subqueries in the from clause, however iirc,
the subquerys require an alias.

If you decide to do geo then the PostGis addon to Postgres is very
nice.

Another nice capability in PostgreSQL is that you can use different
languages for writing your stored procedures (should you wish to use
them). Some of the available languages (in addition to PL/pgSQL) are
Perl, Python, Tcl, PHP, Ruby, R, Scheme, and Java.

Whether you choose to use Postgres or not, I'd recommend at least
looking at it. There is even a live cd (which I have not tried) at
http://www.postgresql.org/download/ which lets you try PostgreSQL out
without having to install it.



On Sep 4, 7:38 pm, Joshua Russo <josh.r.ru...@gmail.com> wrote:
> On Fri, Sep 4, 2009 at 11:07 PM, Tim Chase
> <django.us...@tim.thechases.com>wrote:
>
>
>
>
>
> > > I personally don't have any experience with PostgreSQL and I'm generally
> > > working in a mixed MS and Linux environment. I'm interested to hear
> > peoples
> > > views on the pluses and minuses of the two different systems. I'm a bit
> > of a
> > > query geek too. How does that play in? I know in MySQL there are
> > limitations
> > > on where you can use subqueries. Is that true with PostgreSQL? (Ya I
> > could
> > > just look that one up but it's just an example.)
>
> > I did a writeup of MySQL vs. PostgreSQL a while back:
>
> >http://www.mail-archive.com/django-users@googlegroups.com/msg70188.html
>
> > Most of the issues still stand -- though I understand MySQL now
> > has native(ish) support for Geo information (check the GeoDjango
> > code to see if it supports the MySQL Geo implementation -- last I
> > checked the source it was Oracle & PostgreSQL only).
>
> > To answer your direct question, PostgreSQL has long-standing
> > support for all kinds of crazy sub-queries.  MySQL has added most
> > of those abilities over time.  This used to be a deal-breaker for
> > me, making Postgres the clear winner.  Now they're about even.
>
> > Lastly, my closing arguments in that link still stand -- if you
> > don't have a pressing need to choose one or the other, code &
> > test for both.
>
> Good point on geo side side of things.
>
> One place I have found subqueries very useful is in the From. Functionally
> identical to a view but you don't need to clutter the database with rarely
> used views. That and you can use variables. If you really wanted to get
> fancy you can even nest them. It can save a lot on application logic and
> produce some interesting reports. I don't believe either of our friends here
> support them though. That is one feature I would love to see.
>
> I tend to agree with your closing arguments. I try to stay away from any
> DBMS unique functionality. I very rarely even find much of a need for
> triggers and/or stored procedures. (But they can come in exceptionally handy
> when turning 10s of 1000s of rows of un-normalized data, into close to a
> million rows of normalized. Done in a matter of minutes!)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to