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
|
Список | 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 по дате отправления: