From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Truncate if exists |
Date: | 2012-10-15 14:34:13 |
Message-ID: | CAM-w4HNfEpP5fMvx8Stinmh_KaZC0QKMG4OXz6XYqt=Wuw2-1Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 15, 2012 at 3:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> To be perfectly frank, I think that's exactly where we ought to be
> going. Oracle and Microsoft both did it, so why are we convinced it's
> a bad idea? One of the huge problems with PL/pgsql is that every SQL
> expression in there has to be passed to the executor separately, which
> is painfully slow.
I'm a bit lost. I would think pl/pgsql is precisely the same as
Oracle's pl/sql and MS's T-SQL. I see the complaint you have as a
purely implementation detail. I don't think pl/pgsql is the best
implemented part of Postgres but I don't see how integrating it into
the core is going to automatically make it all wonderful either.
Fwiw my experience has consistently been that life got better whenever
I moved anything I had implemented as PL/SQL or PL/pgsql into client
code in Perl or Python.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-10-15 14:35:02 | Re: Hash id in pg_stat_statements |
Previous Message | Robert Haas | 2012-10-15 14:28:17 | Re: [PATCH] explain tup_fetched/returned in monitoring-stats |