Re: hstore ==> and deprecate =>

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: hstore ==> and deprecate =>
Дата
Msg-id 25227.1276347462@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: hstore ==> and deprecate =>  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: hstore ==> and deprecate =>  (Florian Pflug <fgp@phlo.org>)
Re: hstore ==> and deprecate =>  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список 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 по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: Proposal for 9.1: WAL streaming from WAL buffers
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: hstore ==> and deprecate =>