Awhile back I complained that while all the core geometric datatypes
use operator @ to mean "contained in" and operator ~ to mean "contains",
contrib/cube and contrib/seg switch the meanings:
http://archives.postgresql.org/pgsql...6/msg01238.php

There was some followup discussion generally agreeing that we ought to
get these things in sync, but then Andrew@supernews threw a monkey
wrench into the proceedings by suggesting we change to different names
entirely:
http://archives.postgresql.org/pgsql...6/msg01263.php
That is not necessarily a bad idea, but I didn't want to get drawn
into a debate about exactly what alternative names to adopt, so I
dropped the problem for the time being.

I now find that the GIN patch has propagated the contrib meanings
of these operators into the core:
http://archives.postgresql.org/pgsql...9/msg00087.php
and at this point I'm going to put my foot down and insist that
we do *something*. I won't hold still for fundamentally backward
meanings of the same operator name within the core datatypes.

I can see various things that we might consider doing:

1. Just flip the names of the two operators added by the GIN patch.

2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that contrib/intarray is out
of step too ... are there others?).

3. Leave the existing op names as-is in core and contrib, but consider
them deprecated and add new ops with consistently-chosen names.
(The new ops introduced by GIN should only exist with the new names.)

#1 isn't doing anything towards solving the underlying problem.
#2 has got obvious backwards-compatibility issues for contrib users.
#3 may or may not be technically feasible (I'm not sure if we can
support multiple operators occupying the same slot in an opclass),
besides which choosing the names to use could degenerate to a flamewar.

Thoughts, votes, better ideas? The only option I'm *not* open to is
leaving HEAD as it stands.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> I can see various things that we might consider doing:
>
> 1. Just flip the names of the two operators added by the GIN patch.
>
> 2. #1 plus flip the names of the various contrib operators that are
> out of sync (Michael Fuhr points out that contrib/intarray is out
> of step too ... are there others?).
>
> 3. Leave the existing op names as-is in core and contrib, but consider
> them deprecated and add new ops with consistently-chosen names.
> (The new ops introduced by GIN should only exist with the new names.)
>
> #1 isn't doing anything towards solving the underlying problem.
> #2 has got obvious backwards-compatibility issues for contrib users.

+1 on #2 with the following caveat. When we publish the release notes,
we have a specific section that says:

Compatibility changes from previous releases. Which IMHO should be there
anyway as there are always compatibility issues from release to release.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sun, 3 Sep 2006, Joshua D. Drake wrote:

>
>> I can see various things that we might consider doing:
>>
>> 1. Just flip the names of the two operators added by the GIN patch.
>>
>> 2. #1 plus flip the names of the various contrib operators that are
>> out of sync (Michael Fuhr points out that contrib/intarray is out
>> of step too ... are there others?).
>>
>> 3. Leave the existing op names as-is in core and contrib, but consider
>> them deprecated and add new ops with consistently-chosen names.
>> (The new ops introduced by GIN should only exist with the new names.)

#3 looks good to me. Too many users. We should give them time for
upgrading. Probably, we need special chapter "To be obsoleted in the next
release" in Release notes.

>>
>> #1 isn't doing anything towards solving the underlying problem.
>> #2 has got obvious backwards-compatibility issues for contrib users.
>
> +1 on #2 with the following caveat. When we publish the release notes, we
> have a specific section that says:
>
> Compatibility changes from previous releases. Which IMHO should be there
> anyway as there are always compatibility issues from release to release.
>
> Joshua D. Drake
>
>

Regards,
Oleg
__________________________________________________ ___________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Oleg Bartunov wrote:
> On Sun, 3 Sep 2006, Joshua D. Drake wrote:
>
>>
>>> I can see various things that we might consider doing:
>>>
>>> 1. Just flip the names of the two operators added by the GIN patch.
>>>
>>> 2. #1 plus flip the names of the various contrib operators that are
>>> out of sync (Michael Fuhr points out that contrib/intarray is out
>>> of step too ... are there others?).
>>>
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>> them deprecated and add new ops with consistently-chosen names.
>>> (The new ops introduced by GIN should only exist with the new names.)
>
> #3 looks good to me. Too many users. We should give them time for
> upgrading. Probably, we need special chapter "To be obsoleted in the next
> release" in Release notes.

Users will have time to upgrade should they be responsible. Nobody in
their right might is going to upgrade to 8.2 on a production site the
day it is released.

They are going to test it with their code, and their work load. If it
takes them an extra day to implement query changes (or even an extra
month), good. It will serve them better in the long run.

Sincerely,

Joshua D. Drake


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Oleg Bartunov <oleg@sai.msu.su> writes:
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>> them deprecated and add new ops with consistently-chosen names.
>>> (The new ops introduced by GIN should only exist with the new names.)

> #3 looks good to me. Too many users.

Not only that, but it'd be a serious problem for something like a SQL
script to be cross-version-compatible if we reverse the meanings of the
existing operators.

AFAIK all the operators in question exist only in GIST opclasses, so one
possible solution to the multiple-operators-per-slot problem is to
extend the opclasses --- ie, teach the gist_consistent methods to
support two different strategy numbers that do the same thing. Ugly
and tedious, but it'd preserve backward compatibility.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
> Awhile back I complained that while all the core geometric datatypes
> use operator @ to mean "contained in" and operator ~ to mean "contains",
> contrib/cube and contrib/seg switch the meanings:
> http://archives.postgresql.org/pgsql...6/msg01238.php
>
> There was some followup discussion generally agreeing that we ought to
> get these things in sync, but then Andrew@supernews threw a monkey
> wrench into the proceedings by suggesting we change to different names
> entirely:
> http://archives.postgresql.org/pgsql...6/msg01263.php
> That is not necessarily a bad idea, but I didn't want to get drawn
> into a debate about exactly what alternative names to adopt, so I
> dropped the problem for the time being.
>
> I now find that the GIN patch has propagated the contrib meanings
> of these operators into the core:
> http://archives.postgresql.org/pgsql...9/msg00087.php
> and at this point I'm going to put my foot down and insist that
> we do *something*. I won't hold still for fundamentally backward
> meanings of the same operator name within the core datatypes.
>
> I can see various things that we might consider doing:
>
> 1. Just flip the names of the two operators added by the GIN patch.
>
> 2. #1 plus flip the names of the various contrib operators that are
> out of sync (Michael Fuhr points out that contrib/intarray is out
> of step too ... are there others?).
>
> 3. Leave the existing op names as-is in core and contrib, but consider
> them deprecated and add new ops with consistently-chosen names.
> (The new ops introduced by GIN should only exist with the new names.)
>
> #1 isn't doing anything towards solving the underlying problem.
> #2 has got obvious backwards-compatibility issues for contrib users.
> #3 may or may not be technically feasible (I'm not sure if we can
> support multiple operators occupying the same slot in an opclass),
> besides which choosing the names to use could degenerate to a flamewar.
>
> Thoughts, votes, better ideas? The only option I'm *not* open to is
> leaving HEAD as it stands.
>
>
>
>

How about?:

4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
deprecate the operators for both contrib and core. Something more
visually like set ops would be ideal.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

I also vote +1 for #3. Not only are there too many users, but simply
switching the sense of these operators will mean that code will still run,
but give incorrect answers and while it would be nice to think that all
client code has decent regression testing, this ain't the case.

If we are going to fix things so that all packages use the same sense, we
should slowly deprecate the current notation, and outright drop it for 8.2
or 8.3. What is the concensus: do it this release or next?

I also like the '@<' and '@>' notation as this gives a clear visual cue.

Josh Reich

> Oleg Bartunov <oleg@sai.msu.su> writes:
>>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>>> them deprecated and add new ops with consistently-chosen names.
>>>> (The new ops introduced by GIN should only exist with the new names.)
>
>> #3 looks good to me. Too many users.
>
> Not only that, but it'd be a serious problem for something like a SQL
> script to be cross-version-compatible if we reverse the meanings of the
> existing operators.
>
> AFAIK all the operators in question exist only in GIST opclasses, so one
> possible solution to the multiple-operators-per-slot problem is to
> extend the opclasses --- ie, teach the gist_consistent methods to
> support two different strategy numbers that do the same thing. Ugly
> and tedious, but it'd preserve backward compatibility.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Andrew Dunstan <andrew@dunslane.net> writes:
> How about?:
> 4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
> deprecate the operators for both contrib and core. Something more
> visually like set ops would be ideal.

If we're going to adopt new preferred names, I see no reason to support
the old confusing names for operators that have never existed before
8.2. There is no backward-compatibility argument to be made there.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:

> I can see various things that we might consider doing:
>
> 1. Just flip the names of the two operators added by the GIN patch.
>
> 2. #1 plus flip the names of the various contrib operators that are
> out of sync (Michael Fuhr points out that contrib/intarray is out
> of step too ... are there others?).
>
> 3. Leave the existing op names as-is in core and contrib, but consider
> them deprecated and add new ops with consistently-chosen names.
> (The new ops introduced by GIN should only exist with the new names.)
>
> #1 isn't doing anything towards solving the underlying problem.
> #2 has got obvious backwards-compatibility issues for contrib users.
> #3 may or may not be technically feasible (I'm not sure if we can
> support multiple operators occupying the same slot in an opclass),
> besides which choosing the names to use could degenerate to a flamewar.

I suggest: #4 Standardize on new names and completely drop old naming
scheme, both in core and in contrib.

#2 is much too dangerous, because people may not recognize that their
code needs updating. #3 introduces new code in core that has no other
legitimate purpose (or does someone see a reason why this is generally
useful?)

#4 would force people to notice that their code needs updating, which is
far safer than hoping people will notice.

mark

Mark Dilger <pgsql@markdilger.com> writes:
> I suggest: #4 Standardize on new names and completely drop old naming
> scheme, both in core and in contrib.

Deliberately breaking code that has always worked doesn't sound very
appetizing to me. If there were simply no good alternative to it, then
maybe, but generally we have higher regard for backwards compatibility
than to do it just because it's neater.

I agree with planning to arrive at state #4 after a transitional release
or three, but to do it now with no warning will simply bring us visits
from angry pitchfork-bearing villagers...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org