Re: hstore ==> and deprecate => - Mailing list pgsql-hackers

From Tom Lane
Subject Re: hstore ==> and deprecate =>
Date
Msg-id 25227.1276347462@sss.pgh.pa.us
Whole thread Raw
In response to Re: hstore ==> and deprecate =>  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: hstore ==> and deprecate =>  (Florian Pflug <fgp@phlo.org>)
Re: hstore ==> and deprecate =>  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.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


pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: Proposal for 9.1: WAL streaming from WAL buffers
Next
From: Florian Pflug
Date:
Subject: Re: hstore ==> and deprecate =>