On 07/21/2015 07:28 PM, Alexander Korotkov wrote:
On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas wrote:
In this version of patch it's not checked if variable is actually and int[]
not query_int. See following test case.
# create table test2 as (select '1'::query_int val from
generate_seri
On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas wrote:
> On 07/21/2015 03:44 PM, Alexander Korotkov wrote:
>
>> While Uriy is on vacation, I've revised this patch a bit.
>>
>
> I whacked this around quite a bit, and I think it's in a committable state
> now. But if you could run whatever test
On 07/21/2015 03:44 PM, Alexander Korotkov wrote:
While Uriy is on vacation, I've revised this patch a bit.
I whacked this around quite a bit, and I think it's in a committable
state now. But if you could run whatever tests you were using before on
this, to make sure it still produces the sam
On Tue, Jul 21, 2015 at 5:14 PM, Teodor Sigaev wrote:
> Some notices about code:
>
> 1 Near function transformOperator() there is wrong operator name "@<"
>
Fixed.
> 2 int_query (and intquery) should be replaced to query_int to be
> consistent with actual type name. At least where it's used as
Some notices about code:
1 Near function transformOperator() there is wrong operator name "@<"
2 int_query (and intquery) should be replaced to query_int to be consistent with
actual type name. At least where it's used as separate lexeme.
3 For historical reasons @@ doesn't commutate with itself
Hi!
While Uriy is on vacation, I've revised this patch a bit.
On Tue, Jul 14, 2015 at 8:55 PM, Jeff Janes wrote:
> Hi Uriy,
>
> This patch looks pretty good.
>
> The first line of intarray--1.1.sql mis-identifies itself as "/*
> contrib/intarray/intarray--1.0.sql */"
>
Fixed.
> The real file
On Tue, May 26, 2015 at 4:58 AM, Uriy Zhuravlev
wrote:
> Hello.
>
> Attached patch based on:
>
> http://www.postgresql.org/message-id/capphfdssy+qepdcovxx-b4lp3ybr+qs04m6-arggknfk3fr...@mail.gmail.com
>
> and adds selectivity estimation functions to @@ (port from tsquery). Now we
> support &&, @>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> For the specific cases you mention, perhaps it would be all right if we
>> taught plancache.c to blow away *all* cached plans upon seeing any change
>> in pg_operator; but that seems like a brute-force solution.
> Agreed that it is
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alexander Korotkov writes:
> > My proposal is to let ALTER OPERATOR change restrict and join selectivity
> > functions of the operator. Also it would be useful to be able to change
> > commutator and negator of operator: extension could add commutators and
Oleg Bartunov writes:
> Any chance to have this patch in 9.5 ? Many intarray users will be happy.
Considering how desperately behind we are on reviewing/committing patches
that were submitted by the deadline, I don't think it would be appropriate
or fair to add on major new patches that came in m
Alexander Korotkov writes:
> My proposal is to let ALTER OPERATOR change restrict and join selectivity
> functions of the operator. Also it would be useful to be able to change
> commutator and negator of operator: extension could add commutators and
> negators in further versions. Any thoughts?
Any chance to have this patch in 9.5 ? Many intarray users will be happy.
On Wed, Apr 29, 2015 at 1:48 PM, Alexander Korotkov
wrote:
> Hackers,
>
> currently built-in &&, @>, <@ array operators have selectivity estimations
> while same operator in intarray contrib haven't them. Problem is that
>
12 matches
Mail list logo