"Pavel Stehule" <[EMAIL PROTECTED]> writes: > 2008/12/9 Tom Lane <[EMAIL PROTECTED]>: >> "Pavel Stehule" <[EMAIL PROTECTED]> writes: >>> 2008/12/9 Tom Lane <[EMAIL PROTECTED]>: >>>> ... and it breaks an operator that's already in use. >> >>> what is acceptable workaround? I unhappy, so this symbol was used for >>> this minor contrib module (for this operator doesn't exists regress >>> test). >> >> If you could prove that it were *only* being used by this contrib module >> then I might hold still for replacing it. But you can't. The odds are >> good that people have custom data types using similarly-named operators. > > it means, so we must not implement any new operator?
Operators mean something specific in Postgres. You're talking about implementing a new fundamental syntax but using a token that's indistinguishable from the set of operators. This is a case where Postgres and these other databases have just diverged and copying their syntax would break with Postgres's in a major way. It just doesn't fit. Consider for example things like foo => bar foo =>= bar foo @> bar How would a user recognise which of these are legal operator names? Incidentally -- EDB selling Oracle compatibility may put me in a questionable position here -- the more Oracle incompatibilities in stock Postgres the better for us. But afaik we don't emulate => anyways so that hardly matters. If anything it shows how unimportant it is to worry about being compatible on this front. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
