Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
Дата
Msg-id 447166.1696969927@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges  (Tommy Pavlicek <tommypav122@gmail.com>)
Ответы Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges  (Tommy Pavlicek <tommypav122@gmail.com>)
Список pgsql-hackers
Tommy Pavlicek <tommypav122@gmail.com> 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 happens.

> In other words, if A and B are a pair of commutators and one creates
> another operator, C, with A as its commutator, then C will link to A,
> but A will still link to B (and B to A). It's not clear to me if this
> in itself is a problem, but unless I've misunderstood something
> operator C must be the same as B so it implies an error by the user
> and there could also be issues if A was deleted since C would continue
> to refer to the deleted A.

Yeah, it'd make sense to tighten that up.  Per the discussion so far,
we should not allow an operator's commutator/negator links to change
once set, so overwriting the existing link with a different value
would be wrong.  But allowing creation of the new operator to proceed
with a different outcome than expected isn't good either.  I think
we should start throwing an error for that.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tommy Pavlicek
Дата:
Сообщение: Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
Следующее
От: David Steele
Дата:
Сообщение: Re: The danger of deleting backup_label