[HACKERS] Potential pointer dereference in plperl.c (caused by transforms patch)

Hi all, Coverity is pointing out that as argtypes = NULL in plperl_call_perl_func@plperl.c, we will have a pointer dereference if desc->arg_arraytype[i] is not a valid OID, see here: + Oid*argtypes = NULL; [...] + if (fcinfo->flinfo->fn_oid) + get_func_sig

[HACKERS] Transforms patch not respecting if indentation

Hi all, Coverity complained about a small indentation issue in ruleutils.c: + appendStringInfoString(buf, "\n TRANSFORM "); + for (i = 0; i < ntypes; i++) + { + if (i != 0) + appendStringInfoString(buf, "

[HACKERS] Resource leak in pg_dump.c caused by transforms

Hi all, Coverity is complaining that getTransforms in pg_dump.c leaks a PQExpBuffer allocation. Please find attached a patch to fix the leak. Regards, -- Michael diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index 977b72e..dccb472 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/

Re: [HACKERS] JSON data type and schema validation

On 05/03/2015 11:20 PM, Dmitry Shirokov wrote: Hi all, Are there any plans to introduce in next versions of Postgres a schema validation for JSON field type? It would be very nice to have a support of something like json-schema spec, see http://json-schema.org/documentation.html. Right now t

[HACKERS] JSON data type and schema validation

Hi all, Are there any plans to introduce in next versions of Postgres a schema validation for JSON field type? It would be very nice to have a support of something like json-schema spec, see http://json-schema.org/documentation.html. Right now there's the only way to do it via individual constrain

Re: [HACKERS] optimization join on random value

On 5/3/15 4:15 PM, Anton wrote: Hello guru of postgres, it's possoble to tune query with join on random string ? i know that it is not real life example, but i need it for tests. Moving to -general, which is the proper list for this. (BCC -hackers) > soe-# WHERE customer_id = trunc( r

Re: [HACKERS] CTE optimization fence on the todo list?

On 5/3/15 11:59 AM, Andrew Dunstan wrote: On 05/03/2015 11:49 AM, Tom Lane wrote: Andrew Dunstan writes: On 05/01/2015 07:24 PM, Josh Berkus wrote: (A possible compromise position would be to offer a new GUC to enable/disable the optimization globally; that would add only a reasonably small

Re: [HACKERS] Cast has higher precedence than -

Jim Nasby writes: > The problem is that :: binds more tightly than - This is well known, and even well documented. > Is this by design? If not, any ideas how bad it'd be to fix? It is by design. The core argument for doing it is that '-' might have type-dependent semantics that would not be re

[HACKERS] Cast has higher precedence than -

Given this domain... CREATE DOMAIN loan.loan_amount numeric(7,2) --loan.loan_amount_raw CONSTRAINT loan_amount__greater_equal_0 CHECK( VALUE >= 0 ) CONSTRAINT loan_amount__less_equal_2 CHECK( VALUE <= 2 ) ; I was rather surprised by select -1::loan.loan_amount; ?column?

[HACKERS] optimization join on random value

Hello guru of postgres, it's possoble to tune query with join on random string ? i know that it is not real life example, but i need it for tests. soe=# explain soe-# SELECT ADDRESS_ID, soe-# CUSTOMER_ID, soe-# DATE_CREATED, soe-# HOUSE_NO_OR_NAME, soe-#

Re: [HACKERS] initdb start server recommendation

On May 1, 2015 17:09, "Andrew Dunstan" wrote: > > > On 05/01/2015 10:14 AM, Bruce Momjian wrote: >> >> Currently initdb outputs suggested text on starting the server: >> >> Success. You can now start the database server using: >> >> /u/pgsql/bin/postgres -D /u/pgsql/data >>

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

Pavel Stehule writes: > Some slowdown is visible (about 10%) for query > update foo set a = a || 1; > Significant slowdown is on following test: > do $$ declare a int[] := '{}'; begin for i in 1..9 loop a := a || 10; > end loop; end$$ language plpgsql; > do $$ declare a numeric[] := '{}'; b

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

Hi I did some test with unlogged table in shared buffers foo(a int[]); -- 2K long array 100K rows for queries select max(v) from (unnest(a) from foo) x; select max(a[1]) from foo select max(a[2000]) from foo I didn't find significant slowdown. Some slowdown is visible (about 10%) for query

Re: [HACKERS] [COMMITTERS] pgsql: Add transforms feature

Peter Eisentraut writes: > On 4/26/15 12:36 PM, Tom Lane wrote: >> I don't know why this patch is fooling around with compile/link flags, >> but it's broken at least prairiedog > The addition of the link flag -undefined dynamic_lookup is so that > plugins can refer to symbols from other plugins.

Re: [HACKERS] procost for to_tsvector

I wrote: > Andrew Gierth writes: >> "Tom" == Tom Lane writes: >> Tom> and some experiments of my own, but I wonder why we are only >> Tom> thinking of to_tsvector. Isn't to_tsquery, for example, just >> Tom> about as expensive? What of other text search functions? >> Making the same change for

Re: [HACKERS] CTE optimization fence on the todo list?

On 05/03/2015 11:49 AM, Tom Lane wrote: Andrew Dunstan writes: On 05/01/2015 07:24 PM, Josh Berkus wrote: (A possible compromise position would be to offer a new GUC to enable/disable the optimization globally; that would add only a reasonably small amount of control code, and people who were

Re: [HACKERS] CTE optimization fence on the todo list?

Andrew Dunstan writes: > On 05/01/2015 07:24 PM, Josh Berkus wrote: >>> (A possible compromise position would be to offer a new GUC to >>> enable/disable the optimization globally; that would add only a reasonably >>> small amount of control code, and people who were afraid of the change >>> break

Re: [HACKERS] Loss of some parts of the function definition

Thank you Jim! Views, they also have the problem. In my practice I use them very little, so do not just remember them. Somewhere I read that already are going to introduce their storage source. If I find this source, then I write the link here. I am a supporter of conservation of the source code. I

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

Hi, Jim.Thanks for review.2 мая 2015 г., в 2:10, Jim Nasby написал(а):On 5/1/15 11:19 AM, Vladimir Borodin wrote:There are situations in which vacuuming big btree index causes stuck inWAL replaying on hot standby servers for quite a long time. I’vedescribed the problem in

Re: [HACKERS] Implementing SQL ASSERTION

> On 3 May 2015, at 02:42, David Fetter wrote: > > On Sat, May 02, 2015 at 10:42:24PM +0100, Joe Wildish wrote: >> >> I may start writing up on a blog of where I get to, and then post further to >> this list, if there is interest. > > I suspect that you would get a lot further with a PoC patc