Re: hstore ==> and deprecate =>

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
>> But a reference would be a datatype no? So we could just regard that as
>> an ordinary operator. I don't see a reason why it would conflict with
>> use of the same operator name for other datatypes (unlike the situation
>> with =>).

> The right side of the -> would be an identifier, like
> (some expr yielding a ref)->attribute
> or
> objref->method(args)

Yeah, but the *left* side still has to be a special datatype that
doesn't exist today. So we have at least some chance of not usurping
existing usages of the operator name. In principle you could have
transformAExprOp transform the left side and then check for this case
before trying to transform the right side.

(And in any case, I haven't noticed anybody expressing any interest
in implementing that part of the spec.)

But actually, there's another issue here: hstore defines not one but
three => operators:

text => text yields hstore (with 1 element)
text[] => text[] yields hstore (with N elements)
hstore => text[] yields hstore (subset)

It's reasonable to say that the first two are bad design, but I'm
a bit less willing to say that the last one is. What shall we
do with that?

regards, tom lane