From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: hstore ==> and deprecate => |
Date: | 2010-06-18 21:35:16 |
Message-ID: | AANLkTimtZx0pY5pwa7ZeqzLePvlAaUA_sEakqLYwu88z@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> We don't have a slice operator for arrays; would we be happy with %> being such an operator in a future version? And, does the spec say anything about array operators?
>
Personally, I don't find any of these proposals terribly intuitive.
You know we don't really need an operator at all. slice(hash,
array[1,2,3]) seems like not much typing overhead over hash %
array[1,2,3] and clearer to boot. The only real advantage to having
operators is for operators used to define opclasses. I can't see this
ever being used in such a circumstance (but perhaps I'm not
imaginative enough for GIST indexes these days) so unless there's a
clear analogy to some basic operator that makes code clearer I would
suggest it's not really buying us anything to define an operator name
at all.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Adams | 2010-06-18 22:17:50 | Re: extensible enum types |
Previous Message | Robert Haas | 2010-06-18 21:29:23 | Re: About tapes |