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 '% %',
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
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
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
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
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
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
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
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
Many thanks Tom and David for clarifying the semantics.
/Joel
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
11 matches
Mail list logo