Some people on the #postgresql irc channel pointed out that it's a known
issue.
http://www.qaix.com/postgresql-database-development/246-557-select-based-on-function-result-read.shtml
A more simple testcase is below. Adding OFFSET 0 to the inner query does
indeed fix it in my case.
SELECT
tmp.
Mhh. I have no clue about the internals of PostgreSQL and query planing,
but to me as user this should really be a thing the optimizer has to
work out..
On 03.04.2005 10:01, PFC wrote:
Noticed this problem,too.
You can always make the calculation you want done once inside a set
returni
Noticed this problem,too.
You can always make the calculation you want done once inside a set
returning function so it'll behave like a table, but that's ugly.
On Mon, 28 Mar 2005 16:14:44 +0200, Hannes Dorbath
<[EMAIL PROTECTED]> wrote:
hm, a few days and not a single reply :|
any more inf
hm, a few days and not a single reply :|
any more information needed? test data? simplified test case? anything?
thanks
Hannes Dorbath wrote:
The query and the corresponding EXPLAIN is at
http://hannes.imos.net/query.txt
I'd like to use the column q.replaced_serials for multiple calculations
in the
Thank you very much for your reply. I'll try to modify it.
Josh Berkus wrote:
Hannes,
The query and the corresponding EXPLAIN is at
http://hannes.imos.net/query.txt
The problem is that you're using a complex corellated sub-select in the SELECT
clause:
SELECT
d.delivery_id,
da.ar
Hannes,
> The query and the corresponding EXPLAIN is at
>
> http://hannes.imos.net/query.txt
The problem is that you're using a complex corellated sub-select in the SELECT
clause:
SELECT
d.delivery_id,
da.article_no,
da.amount,
(
SELECT
COUNT(*)
