Raise exception without using plpgsql?

2020-12-17 Thread Joel Jacobson
Hi, Is there a way to raise an exception with a message, without having to add your own plpgsql helper-function? Currently this is what I have: CREATE OR REPLACE FUNCTION raise(message text, debug json, dummy_return_value anyelement) RETURNS anyelement LANGUAGE plpgsql AS $$ BEGIN RAISE '% %',

Avoid undesired flattening of jsonb arrays?

2020-12-18 Thread Joel Jacobson
The || operator for the jsonb type has a surprising behaviour. Instead of appending the right operand "as is" to the left operand, it has a magic behaviour if the right operand is an array, in which case it will append the items of the array, instead of appending the array itself as a single value

Re: Avoid undesired flattening of jsonb arrays?

2020-12-18 Thread Joel Jacobson
The following nicer work-around was suggested to me by Andreas Karlsson: -jsonb_insert(x.jsonb_array,'{-1}',next_item.item,TRUE) +x.jsonb_array || jsonb_build_array(next_item.item) On Fri, Dec 18, 2020, at 17:20, Tom Lane wrote: > "David G. Johnston" writes: > > I'll agree that the desc

Avoid excessive inlining?

2020-12-18 Thread Joel Jacobson
Is there a way to avoid excessive inlining when writing pure SQL functions, without having to use PL/pgSQL? The JOIN LATERAL and Nested Subqueries versions run much slower than the PL/pgSQL version: Execution Times: JOIN LATERAL: 12198.010 ms Nested Subqueries: 12250.077 ms PL/pgSQL: 312.493 ms

Re: Avoid excessive inlining?

2020-12-22 Thread Joel Jacobson
On Tue, Dec 22, 2020, at 14:40, Laurenz Albe wrote: >I would say that the simplest way to prevent a function from being inlined >is to set a parameter on it: > ALTER FUNCTION f() SET enable_seqscan = on; Thanks, very useful, didn't know about that trick. I think I was a bit unclear about my prob

Re: Avoid excessive inlining?

2020-12-22 Thread Joel Jacobson
xt_item.sql | 109 - Makefile| 8 expected/rfc7049_appendix_a.out | 52 +++- 11 files changed, 304 insertions(+), 86 deletions(-) Best regards, Joel On Tue, Dec 22, 2020, at 17:32, Tom Lane wrote: "Joel Jaco

Re: Avoid excessive inlining?

2021-01-02 Thread Joel Jacobson
9 ms (4 rows) On Tue, Dec 22, 2020, at 17:32, Tom Lane wrote: > "Joel Jacobson" writes: > > I think I was a bit unclear about my problem, and might have used the wrong > > terminology. > > In my LATERAL query, there are calculations in a certain order. > > F

Re: Avoid excessive inlining?

2021-01-02 Thread Joel Jacobson
13.1 On Sat, Jan 2, 2021, at 20:37, Pavel Stehule wrote: > Hi > > so 2. 1. 2021 v 20:07 odesílatel Joel Jacobson napsal: >> __ >> I found yet another trick, which actually seems to be slightly faster than >> the plpgsql version. > > What version of Pos

CASE WHEN idiomatic for functions with side-effect?

2021-01-12 Thread Joel Jacobson
Is it idiomatic and safe to use SELECT CASE boolean_expression WHEN TRUE THEN function_with_side_effects() END ... in a query to ensure the function_with_side_effects() is only execute if boolean_expression is true? function_with_side_effects() is known to be a normal function, and not an aggr

Re: CASE WHEN idiomatic for functions with side-effect?

2021-01-12 Thread Joel Jacobson
Many thanks Tom and David for clarifying the semantics. /Joel

Planning time grows exponentially with levels of nested views

2021-04-18 Thread Joel Jacobson
Hi, I assumed the cost for each nested VIEW layer would grow linear, but my testing shows it appears to grow exponentially: CREATE TABLE foo (bar int); INSERT INTO foo (bar) VALUES (123); DO $_$ DECLARE BEGIN CREATE OR REPLACE VIEW v1 AS SELECT * FROM foo; FOR i IN 1..256 LOOP EXECUTE format