Christoph Berg writes:
> I wish there was. The error reporting from failing extension scripts
> is really bad with no context at all, it has hit me a few times in the
> past already.
Nobody's spent any work on that :-(. A really basic reporting
facility is not hard to add, as in the attached fin
Re: Michael Banck
> I guess there's no way to make that error a bit more helpful, like
> printing out the offenbding SQL command, presumably because we are
> loding an extension?
I wish there was. The error reporting from failing extension scripts
is really bad with no context at all, it has hit m
Hi,
On Tue, Oct 24, 2023 at 11:42:15AM -0400, Tom Lane wrote:
> 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 g
Re: To Tom Lane
> Let's keep it like it is now in PG17.
Late followup news: This feature has actually found a bug in
postgresql-debversion:
CREATE OPERATOR > (
LEFTARG = debversion,
RIGHTARG = debversion,
COMMUTATOR = <,
- NEGATOR = >=,
+ NEGATOR = <=,
RESTRICT = scalargtsel,
JO
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 e
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, O
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 it
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 commu
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 and
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
we
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", ope
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
> > c
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 h
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 the
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 sho
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
w
/*
* 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 expe
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 wit
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 t
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 d
=?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 thes
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 th
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 and
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 wi
25 matches
Mail list logo
