Re: WIP: default values for function parameters

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:

> 2008/12/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>>> 2008/12/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>>> ... 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!