Re: Tom Lane
> Well, the idea was exactly to forbid that sort of setup.
Fwiw, pgsphere has remove the problematic operators now:
https://github.com/postgrespro/pgsphere/commit/e810f5ddd827881b06a92a303c5c9fbf997b892e
> However, if we get sufficient pushback maybe we should
> reconsider --- for
On Fri, Oct 20, 2023 at 5:33 PM Tom Lane wrote:
> Pushed after a round of editorialization -- mostly cosmetic
> stuff, except for tweaking some error messages. I shortened the
> test cases a bit too, as I thought they were somewhat excessive
> to have as a permanent thing.
Thanks Tom.
On Tue,
Christoph Berg writes:
> Anyway, if this doesn't raise any "oh we didn't think of this"
> concerns, we'll just remove the old operators in pgsphere.
Well, the idea was exactly to forbid that sort of setup.
However, if we get sufficient pushback maybe we should
reconsider --- for example, maybe
Re: Tom Lane
> > We might be able to simply delete the @ operators, but doesn't this
> > new check break the general possibility to have more than one spelling
> > for the same operator?
>
> You can have more than one operator atop the same function.
> But why didn't you make the @ operators
Christoph Berg writes:
> This change is breaking pgsphere which has <@ @> operator pairs, but
> for historical reasons also includes alternative spellings of these
> operators (both called @ with swapped operand types) which now
> explodes because we can't add them with the "proper" commutator
Re: Tommy Pavlicek
> I've added another patch (0002-require_unused_neg_com-v1.patch) that
> prevents using a commutator or negator that's already part of a pair.
Hmm. I agree with the general idea of adding sanity checks, but this
might be overzealous:
This change is breaking pgsphere which has
jian he writes:
> errmsg("operator attribute \"negator\" cannot be changed if it has
> already been set")));
> I feel like the above message is not very helpful.
I think it's okay to be concise about this as long as the operator
we're referring to is the target of the ALTER. I agree that when
errmsg("operator attribute \"negator\" cannot be changed if it has
already been set")));
I feel like the above message is not very helpful.
Something like the following may be more helpful for diagnosis.
errmsg("operator %s's attribute \"negator\" cannot be changed if it
has already been set",
On Tue, Oct 10, 2023 at 9:32 PM Tom Lane wrote:
>
> Tommy Pavlicek writes:
> > I did notice one further potential bug. When creating an operator and
> > adding a commutator, PostgreSQL only links the commutator back to the
> > operator if the commutator has no commutator of its own, but the
> >
Tommy Pavlicek writes:
> I did notice one further potential bug. When creating an operator and
> adding a commutator, PostgreSQL only links the commutator back to the
> operator if the commutator has no commutator of its own, but the
> create operation succeeds regardless of whether this linkage
On Thu, Sep 28, 2023 at 9:18 PM Tom Lane wrote:
>
> Tommy Pavlicek writes:
> > I've attached a new version of the ALTER OPERATOR patch that allows
> > no-ops. It should be ready to review now.
>
> I got around to looking through this finally (sorry about the delay).
> I'm mostly on board with
Tommy Pavlicek writes:
> I've attached a new version of the ALTER OPERATOR patch that allows
> no-ops. It should be ready to review now.
I got around to looking through this finally (sorry about the delay).
I'm mostly on board with the functionality, with the exception that
I don't see why we
in doc/src/sgml/ref/alter_operator.sgml
HASHES
Indicates this operator can support a hash join. Can only be set
when the operator does not support a hash join.
MERGES
Indicates this operator can support a merge join. Can only be set
/*
* AlterOperator
* routine implementing ALTER OPERATOR SET (option = ...).
*
* Currently, only RESTRICT and JOIN estimator functions can be changed.
*/
ObjectAddress
AlterOperator(AlterOperatorStmt *stmt)
The above comment needs to change, other than that, it passed the
test, works as
On Fri, Jun 23, 2023 at 12:21 PM Tom Lane wrote:
>
> Tommy Pavlicek writes:
> > I've added a single patch here: https://commitfest.postgresql.org/43/4389/
>
> > It wasn't obvious whether I should create a second commitfest entry
> > because I've included 2 patches so I've just done 1 to begin
Tommy Pavlicek writes:
> I've added a single patch here: https://commitfest.postgresql.org/43/4389/
> It wasn't obvious whether I should create a second commitfest entry
> because I've included 2 patches so I've just done 1 to begin with. On
> that note, is it preferred here to split patches of
Tom Lane writes:
> Please add this to the upcoming commitfest [1], to ensure we don't
> lose track of it.
I've added a single patch here: https://commitfest.postgresql.org/43/4389/
It wasn't obvious whether I should create a second commitfest entry
because I've included 2 patches so I've just
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> (Don't we have existing precedents that apply here? I can't offhand
>> think of any existing ALTER commands that would reject no-op requests,
>> but maybe that's not a direct precedent.)
> Since it only supports adding
Tom Lane writes:
> Tommy Pavlicek writes:
>
>> Additionally, I wasn't sure whether it was preferred to fail or succeed on
>> ALTERs that have no effect, such as adding hashes on an operator that
>> already allows them or disabling hashes on one that does not. I chose to
>> raise an error when
Tommy Pavlicek writes:
> I've attached a couple of patches to allow ALTER OPERATOR to add
> commutators, negators, hashes and merges to operators that lack them.
Please add this to the upcoming commitfest [1], to ensure we don't
lose track of it.
> The first patch is create_op_fixes_v1.patch
Hi All,
I've attached a couple of patches to allow ALTER OPERATOR to add
commutators, negators, hashes and merges to operators that lack them.
The need for this arose adding hash functions to the ltree type after the
operator had been created without hash support[1]. There are potential
issues
21 matches
Mail list logo
