On 07/14/2015 07:28 PM, Jeff Janes wrote:
I'm getting some compiler warnings now:
operatorcmds.c: In function 'AlterOperator':
operatorcmds.c:504: warning: 'address.objectSubId' may be used
uninitialized in this function
operatorcmds.c:365: note: 'address.objectSubId' was declared here
operatorc
On Tue, Jul 14, 2015 at 8:22 AM, Heikki Linnakangas wrote:
> On 07/13/2015 03:43 PM, Uriy Zhuravlev wrote:
>
>> Hello hackers.
>>
>> Attached is a new version of patch:
>> * port syntax from NULL to truth NONE
>> * fix documentation (thanks Heikki)
>> * rebase to master
>>
>
> Thanks, committed
On Tuesday 14 July 2015 18:22:26 you wrote:
> I think you had copy-pasted from one of the generic
> ALTER variants, like AlterOwnerStmt, which was overly generic for ALTER
> OPERATOR.
You right.
> Thanks, committed after some editing.
Thanks you. And it BIG editing. ;)
After that, can you vi
On 07/13/2015 03:43 PM, Uriy Zhuravlev wrote:
Hello hackers.
Attached is a new version of patch:
* port syntax from NULL to truth NONE
* fix documentation (thanks Heikki)
* rebase to master
Thanks, committed after some editing. I put all the logic into
AlterOperator function, in operatorcmd
Hello hackers.
Attached is a new version of patch:
* port syntax from NULL to truth NONE
* fix documentation (thanks Heikki)
* rebase to master
Thanks.
--
Uriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/doc/src/sgml/ref/alter_operator
Hello.
On Friday 10 July 2015 15:46:35 you wrote:
> * I think it'd be better to use NONE instead of NULL above, to remove
> the estimator. It seems inconsistent when we've used NONE to mean
> "missing" earlier in the same statement.
Ok, you right.
> * The way you check for the NULL in OperatorU
On 07/06/2015 07:21 PM, Uriy Zhuravlev wrote:
Hello hackers.
This is the fifth version of the patch (the fourth was unsuccessful :)).
I added documentation and was held a small refactoring.
I edited the formatting of the syntax page a bit, and came up with this:
ALTER OPERATOR name ( { left_t
Hello hackers.
This is the fifth version of the patch (the fourth was unsuccessful :)).
I added documentation and was held a small refactoring.
Thanks.
--
Uriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/doc/src/sgml/ref/alter_operator.sgm
On Wed, Jun 24, 2015 at 7:30 AM, Uriy Zhuravlev
wrote:
> Because change the commutator and negator raised questions I suggest 3 version
> of the patch without them. In addition, for us now is much more important
> restrict and join (for "Selectivity estimation for intarray" patch).
Seems broadly
Hello Hackers.
Because change the commutator and negator raised questions I suggest 3 version
of the patch without them. In addition, for us now is much more important
restrict and join (for "Selectivity estimation for intarray" patch).
What do you think?
Thanks!
--
Uriy Zhuravlev
Postgres P
On Fri, May 29, 2015 at 4:28 AM, Alexander Korotkov
wrote:
> On Thu, May 28, 2015 at 6:43 PM, Tom Lane wrote:
>>
>> Alexander Korotkov writes:
>> > Could we address both this problems by denying changing existing
>> > commutators and negator? ISTM that setting absent commutator and negator
>> >
On Thu, May 28, 2015 at 6:43 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > Could we address both this problems by denying changing existing
> > commutators and negator? ISTM that setting absent commutator and negator
> is
> > quite enough for ALTER OPERATOR. User extensions could need set
Alexander Korotkov writes:
> Could we address both this problems by denying changing existing
> commutators and negator? ISTM that setting absent commutator and negator is
> quite enough for ALTER OPERATOR. User extensions could need setting of
> commutator and negator because they could add new o
On Wed, May 27, 2015 at 9:28 PM, Robert Haas wrote:
> On Mon, May 18, 2015 at 10:21 AM, Tom Lane wrote:
> > Uriy Zhuravlev writes:
> >> I have attached a patch that extends ALTER OPERATOR to support
> COMMUTATOR,
> >> NEGATOR, RESTRICT and JOIN.
> >
> > There are fairly significant reasons why
On Mon, May 18, 2015 at 10:21 AM, Tom Lane wrote:
> Uriy Zhuravlev writes:
>> I have attached a patch that extends ALTER OPERATOR to support COMMUTATOR,
>> NEGATOR, RESTRICT and JOIN.
>
> There are fairly significant reasons why we have not done this, based
> on the difficulty of updating existin
Hello Hackers.
I reworked the patch. Now, the syntax is similar to CREATE OPERATOR.
And as I wrote earlier problems with the cache I have not found. If someone
can suggest how it could be verified that would be happy.
New syntax example:
ALTER OPERATOR === (boolean, boolean) SET (COMMUTATOR = =)
On Wednesday 20 May 2015 20:50:41 Andres Freund wrote:
> Note that this very likely wasn't actually using a prepared plan. Due to
> the custom plan infrastructure the first few invocations are going to be
> replanned.
Hello. I tested it on 30 and 50 iterations, and it feels good.
Thanks.
--
Uriy
Hi,
On 2015-05-20 12:22:34 +0300, Uriy Zhuravlev wrote:
> On Monday 18 May 2015 10:21:10 you wrote:
> > difficulty of updating existing cached plans
> Could you specify more precisely about some caches we talking about? PREPARE
> working correctly:
>
> CREATE TABLE test_ints(i int4);
> CREATE TA
Alvaro Herrera writes:
> Uriy Zhuravlev wrote:
>> And can you explain more about the syntax?
> I think he means to treat COMMUTATOR etc like a generic element list,
> i.e. don't define new keywords in kwlist.h/gram.y at all but rather pass
> the names as strings (probably using a list of DefElem)
Uriy Zhuravlev wrote:
> And can you explain more about the syntax?
I think he means to treat COMMUTATOR etc like a generic element list,
i.e. don't define new keywords in kwlist.h/gram.y at all but rather pass
the names as strings (probably using a list of DefElem) and strcmp()
them in OperatorUp
On Monday 18 May 2015 10:21:10 you wrote:
> difficulty of updating existing cached plans
Could you specify more precisely about some caches we talking about? PREPARE
working correctly:
CREATE TABLE test_ints(i int4);
CREATE TABLE
CREATE INDEX idx ON test_ints(i);
CREATE INDEX
set enable_bitmapsca
On Mon, May 18, 2015 at 5:44 PM, Uriy Zhuravlev
wrote:
> On Monday 18 May 2015 10:21:10 Tom Lane wrote:
> > There are fairly significant reasons why we have not done this, based
> > on the difficulty of updating existing cached plans that might have
> > incidentally depended on those operator pro
On Monday 18 May 2015 10:21:10 Tom Lane wrote:
> There are fairly significant reasons why we have not done this, based
> on the difficulty of updating existing cached plans that might have
> incidentally depended on those operator properties during creation.
> Perhaps it's all right to simply ignor
Uriy Zhuravlev writes:
> I have attached a patch that extends ALTER OPERATOR to support COMMUTATOR,
> NEGATOR, RESTRICT and JOIN.
There are fairly significant reasons why we have not done this, based
on the difficulty of updating existing cached plans that might have
incidentally depended on tho
Hello Hackers.
I have attached a patch that extends ALTER OPERATOR to support COMMUTATOR,
NEGATOR, RESTRICT and JOIN. This patch is based on master. It is small patch
with regression tests.
Why do it?
The operator has four important parameters that can be set only during the
creation. These a
25 matches
Mail list logo
