On Fri, Jul 2, 2010 at 5:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane wrote:
>>> Okay, I'm confused. This patch removed an operator named %, which AFAIK
>>> was not controversial. The problematic operator is => no?
>
>> It used to be =>
>
> Nevermind
Robert Haas writes:
> On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane wrote:
>> Okay, I'm confused. This patch removed an operator named %, which AFAIK
>> was not controversial. The problematic operator is => no?
> It used to be =>
Nevermind, I *am* confused. Obviously time to knock off for the day
On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>>> You forgot to attach the patch. :-)
>
>> Attached.
>
> Okay, I'm confused. This patch removed an operator named %, which AFAIK
> was not controversial. The problematic operator is => no?
It used to be =>
After m
"David E. Wheeler" writes:
>> You forgot to attach the patch. :-)
> Attached.
Okay, I'm confused. This patch removed an operator named %, which AFAIK
was not controversial. The problematic operator is => no?
regards, tom lane
--
Sent via pgsql-hackers mailing list (
On Jul 2, 2010, at 1:45 PM, Robert Haas wrote:
>> No, I removed that because that table has only operators, no functions.
>> Seehttp://developer.postgresql.org/docs/postgres/hstore.html.
>
> The section contains two tables. Table F-5 is called "hstore
> operators", and table F-6 is called "hsto
On Fri, Jul 2, 2010 at 4:43 PM, David E. Wheeler wrote:
> On Jul 2, 2010, at 1:38 PM, Robert Haas wrote:
>
>> Thanks, committed - with the exception that I reverted your change to
>> the title of section F.13.2, which I believe was in error (and
>> possibly accidental).
>
> No, I removed that beca
On Jul 2, 2010, at 1:38 PM, Robert Haas wrote:
> Thanks, committed - with the exception that I reverted your change to
> the title of section F.13.2, which I believe was in error (and
> possibly accidental).
No, I removed that because that table has only operators, no functions. See
http://devel
On Fri, Jul 2, 2010 at 2:39 PM, David E. Wheeler wrote:
> On Jul 2, 2010, at 10:07 AM, Robert Haas wrote:
>
Yeah, I think the consensus is to avoid picking an operator name at all.
"slice()" is OK by me.
>>>
>>> Will this be done for Beta 3?
>>
>> You forgot to attach the patch. :-)
>
>
On Jul 2, 2010, at 10:07 AM, Robert Haas wrote:
>>> Yeah, I think the consensus is to avoid picking an operator name at all.
>>> "slice()" is OK by me.
>>
>> Will this be done for Beta 3?
>
> You forgot to attach the patch. :-)
Attached.
Only thing that gave me pause is the presence of the un
On Fri, Jul 2, 2010 at 12:36 PM, David E. Wheeler wrote:
> On Jun 28, 2010, at 12:10 PM, Tom Lane wrote:
>
>>> While I would personally prefer to have an operator for the slicing
>>> opeeration, I'm not willing to spend time arguing about it. So, +1 to
>>> implement the subset operation as the fu
On Jun 28, 2010, at 12:10 PM, Tom Lane wrote:
>> While I would personally prefer to have an operator for the slicing
>> opeeration, I'm not willing to spend time arguing about it. So, +1 to
>> implement the subset operation as the function slice(), and defer having
>> an operator until later.
>
Josh Berkus writes:
> While I would personally prefer to have an operator for the slicing
> opeeration, I'm not willing to spend time arguing about it. So, +1 to
> implement the subset operation as the function slice(), and defer having
> an operator until later.
Yeah, I think the consensus is t
All,
>> I don't much like hstore(hstore, text[]) because it's not strictly a
>> constructor. But I could certainly live with something based on the
>> word slice. The existing SQL function backing the operator is called
>> slice_hstore(), whereas I would probably prefer hstore_slice() or just
>>
On Jun 21, 2010, at 10:46 AM, Robert Haas wrote:
> I don't much like hstore(hstore, text[]) because it's not strictly a
> constructor. But I could certainly live with something based on the
> word slice. The existing SQL function backing the operator is called
> slice_hstore(), whereas I would p
"David E. Wheeler" writes:
> So, frankly, I'm coming back to what Florian has suggested here. What about
> calling it slice?
> hstore = slice(hstore, text[]);
+1, particularly seeing that our solution for the other two cases also
comes down to "use the function instead".
On Mon, Jun 21, 2010 at 1:37 PM, David E. Wheeler wrote:
> On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:
>
>> How about turning it into a function
>> hstore hstore(hstore, text[])
>> instead?
>
> I just searched through the 2008 spec for a slice/subset operator and came up
> empty. It seem
On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:
> How about turning it into a function
>hstore hstore(hstore, text[])
> instead?
I just searched through the 2008 spec for a slice/subset operator and came up
empty. It seems to define a bunch of predicates for multisets, but not much for
ar
On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler 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 intui
On Jun 18, 2010, at 11:20 AM, Greg Stark wrote:
>> +1 from me, too.
>>
>
> 1 isn't a valid character in a postgres operator
Dammit!
This reminds me, I wanted to ask one more thing:
We don't have a slice operator for arrays; would we be happy with %> being such
an operator in a future version
On Fri, Jun 18, 2010 at 6:26 PM, David E. Wheeler wrote:
> +1 from me, too.
>
1 isn't a valid character in a postgres operator
:P
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Jun 18, 2010, at 10:03 AM, Josh Berkus wrote:
>> I'd vote for %>, out of those. Reason: the operator isn't commutative,
>> in fact left and right inputs aren't even the same datatype, so a glyph
>> that looks asymmetric seems more natural.
>
> +1 on %>
+1 from me, too.
Best,
David
--
Sen
I vote for % .
I'd vote for %>, out of those. Reason: the operator isn't commutative,
in fact left and right inputs aren't even the same datatype, so a glyph
that looks asymmetric seems more natural.
+1 on %>
(Frankly, as long as it isn't & or | I can live with it ... )
--
On Thu, Jun 17, 2010 at 11:04 PM, Andrew Dunstan wrote:
>>> I vote for % .
>> I'd vote for %>, out of those. Reason: the operator isn't commutative,
>> in fact left and right inputs aren't even the same datatype, so a glyph
>> that looks asymmetric seems more natural.
> Lots of operators aren't c
Tom Lane wrote:
Josh Berkus writes:
Currently for hstore, %% returns a flattened array and %# returns a
two-dimensional array. That means that it makes sense that the operator
which returns an hstore subset should be something based on %, either
%>, %% or just %.
But %% and %# are
On Jun 17, 2010, at 4:15 PM, Tom Lane wrote:
>> Using % would also mean that sometime in the future we can implement !%
>> as "elements NOT in this list" (i.e. ' a => 1, b => 2, c => 5' !% 'a, b'
>> == 'c => 5' )
>
> You can prepend ! to any operator name at all, so that's not much of
> a differe
Josh Berkus writes:
> Currently for hstore, %% returns a flattened array and %# returns a
> two-dimensional array. That means that it makes sense that the operator
> which returns an hstore subset should be something based on %, either
> %>, %% or just %.
But %% and %# are prefix operators. Ext
On 6/17/10 2:03 PM, David E. Wheeler wrote:
> On Jun 17, 2010, at 1:50 PM, Josh Berkus wrote:
>
>>> It isn't. || already does what you're saying.
>> So what *does* it do?
>
> It returns an hstore that's effectively a slice of another hstore. From the
> docs (http://developer.postgresql.org/pgdo
On Thu, Jun 17, 2010 at 4:50 PM, Josh Berkus wrote:
> On 6/17/10 1:40 PM, Robert Haas wrote:
>> On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus wrote:
Since there are no other votes for that option (or, indeed, any other
option), I'm going to go with my original instinct and change hstore
On Jun 17, 2010, at 1:50 PM, Josh Berkus wrote:
>> It isn't. || already does what you're saying.
>
> So what *does* it do?
It returns an hstore that's effectively a slice of another hstore. From the
docs (http://developer.postgresql.org/pgdocs/postgres/hstore.html):
'a=>1,b=>2,c=>3'::hstore =
On 6/17/10 1:40 PM, Robert Haas wrote:
> On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus wrote:
>>> Since there are no other votes for that option (or, indeed, any other
>>> option), I'm going to go with my original instinct and change hstore
>>> => text[] to hstore & text[]. Patch to do that is att
On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus wrote:
>
>> Since there are no other votes for that option (or, indeed, any other
>> option), I'm going to go with my original instinct and change hstore
>> => text[] to hstore & text[]. Patch to do that is attached.
>
> If what that operator is doing
> Since there are no other votes for that option (or, indeed, any other
> option), I'm going to go with my original instinct and change hstore
> => text[] to hstore & text[]. Patch to do that is attached.
If what that operator is doing is appending an array of text to an
Hstore, shouldn't we use
On Jun 17, 2010, at 2:56 , David E. Wheeler wrote:
> On Jun 16, 2010, at 4:58 PM, Tom Lane wrote:
>
>>> hstore => text[] is new in 9.0.
>>
>> Wup, sorry, I read this as being the other operator. Nevermind ...
>>
>> (FWIW, I share your dislike of & for this operator. I just haven't
>> got a bet
On Jun 16, 2010, at 4:58 PM, Tom Lane wrote:
>> hstore => text[] is new in 9.0.
>
> Wup, sorry, I read this as being the other operator. Nevermind ...
>
> (FWIW, I share your dislike of & for this operator. I just haven't
> got a better idea.)
There aren't any very good choices. Possible corr
"David E. Wheeler" writes:
> On Jun 16, 2010, at 4:53 PM, Tom Lane wrote:
>> Um ... wait a minute. What happened to backwards compatibility?
>> I thought the idea was to deprecate => for a release or so, not kill it
>> on the spot.
> hstore => text[] is new in 9.0.
Wup, sorry, I read this as be
On Jun 16, 2010, at 4:53 PM, Tom Lane wrote:
> Um ... wait a minute. What happened to backwards compatibility?
> I thought the idea was to deprecate => for a release or so, not kill it
> on the spot.
hstore => text[] is new in 9.0.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Robert Haas writes:
> Since there are no other votes for that option (or, indeed, any other
> option), I'm going to go with my original instinct and change hstore
> => text[] to hstore & text[]. Patch to do that is attached.
Um ... wait a minute. What happened to backwards compatibility?
I thou
On Jun 16, 2010, at 4:24 PM, Robert Haas wrote:
>> Put me down for +>.
>
> Since there are no other votes for that option (or, indeed, any other
> option), I'm going to go with my original instinct and change hstore
> => text[] to hstore & text[]. Patch to do that is attached.
Damn. My other ar
On Tue, Jun 15, 2010 at 10:55 PM, David E. Wheeler wrote:
> On Jun 15, 2010, at 6:58 PM, Robert Haas wrote:
>
>> Well, the idea is it's like logical-and - give me only those keys that
>> appear on both sides...
>
> Yeah, but => doesn't return the keys, -> does. => returns an hstore.
>
>> If there
On Jun 15, 2010, at 6:58 PM, Robert Haas wrote:
> Well, the idea is it's like logical-and - give me only those keys that
> appear on both sides...
Yeah, but => doesn't return the keys, -> does. => returns an hstore.
> If there is a critical mass of votes for one of these options, I'm
> fine with
On Tue, Jun 15, 2010 at 9:04 PM, David E. Wheeler wrote:
> On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:
>
>> On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
>> wrote:
>>> I'm happy with deprecating the first two => in favour of hstore() if
>>> that is in line with general opinion. The hstore =>
On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
> wrote:
>> I'm happy with deprecating the first two => in favour of hstore() if
>> that is in line with general opinion. The hstore => text[] slice could
>> be replaced by another operator name; the
On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
wrote:
> I'm happy with deprecating the first two => in favour of hstore() if
> that is in line with general opinion. The hstore => text[] slice could
> be replaced by another operator name; the existing name comes from the
> analogy that (hstore -> t
> "Tom" == Tom Lane writes:
Tom> But actually, there's another issue here: hstore defines not one
Tom> but three => operators:
Tom> text => textyields hstore (with 1 element)
Tom> text[] => text[]yields hstore (with N elements)
Tom> hstore => text[]yiel
On Sat, Jun 12, 2010 at 1:21 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if
>> there was an
>> hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which m
On Jun 12, 2010, at 10:21 AM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if
>> there was an
>>hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which mean
Tom Lane wrote:
> I notice that in 8.4 and before, the function underlying text => text
> wasn't called hstore() but tconvert(). Which is going to be a serious
> PITA for anyone who wants to write cross-version-compatible SQL using
> hstore. Can we do anything about this? I don't think we want t
"David E. Wheeler" writes:
> Which, IIRC, is new in 9.1, so could in theory be removed, especially if
> there was an
> hstore(text[], text[])
Oh --- now that I look, both that and the hstore => text[] one are new
in 9.0, which means it is not too late to reverse course. So at this
point
"David E. Wheeler" writes:
> On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
>>> hstore(key := 'this', key2 := 'that')
>>> hstore(key => 'this', key2 => 'that')
>>> hstore(row('this' AS key, 'that' AS key2))
>>
>> The last of those is probably the easiest to get to. We already have
>> hstore_from_r
On Jun 12, 2010, at 7:15 AM, Florian Pflug wrote:
>> 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?
>
> Hm, the last one seems to be more akin to
>hstore - textyields hstore (key
On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
>> hstore(key := 'this', key2 := 'that')
>> hstore(key => 'this', key2 => 'that')
>> hstore(row('this' AS key, 'that' AS key2))
>
> The last of those is probably the easiest to get to. We already have
> hstore_from_record:
Is not the first one simply
On Jun 12, 2010, at 14:57 , Tom Lane wrote:
> But actually, there's another issue here: hstore defines not one but
> three => operators:
>
> text => textyields hstore (with 1 element)
> text[] => text[]yields hstore (with N elements)
> hstore => text[]
Peter Eisentraut 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 situa
On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> >>> Btw., the SQL standard also defines -> for something else, so if you
> >>> wanted to be really visionary, you could deprecate that one as an
> >>> operator at the same time.
> >>
> >> Ouch. What does it define it
On Fri, Jun 11, 2010 at 5:23 PM, Tom Lane wrote:
> Joseph Adams writes:
>> To repeat an earlier question (which was in turn repeating an earlier
>> question), would it be possible to do one of these, yielding '
>> "key"=>"this", "key2"=>"that" '::hstore :
>
>> hstore(key := 'this', key2 := 'that
Joseph Adams writes:
> To repeat an earlier question (which was in turn repeating an earlier
> question), would it be possible to do one of these, yielding '
> "key"=>"this", "key2"=>"that" '::hstore :
> hstore(key := 'this', key2 := 'that')
> hstore(key => 'this', key2 => 'that')
> hstore(row('
On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> How about no operator at all? It won't be as cool to read, but
>> consider, the arguments are text and text, not involving any hstore type
>> at all, so whatever operator you choose is in practice blocked from
>> eve
On Jun 11, 2010, at 9:58 AM, Tom Lane wrote:
>> That would make it so that the use of => in hstore strings would be less
>> consistent. Makes sense to me.
>
> Less inconsistent, ITYM? But yeah, then we would have no reason to
> fiddle with hstore_in, which is good.
Yes, sorry.
David
--
Sen
"David E. Wheeler" writes:
> On Jun 11, 2010, at 7:59 AM, Tom Lane wrote:
>> Yeah, that's a good point. Maybe we should just deprecate the operator
>> altogether.
> That would make it so that the use of => in hstore strings would be less
> consistent. Makes sense to me.
Less inconsistent, ITYM
On Jun 11, 2010, at 7:59 AM, Tom Lane wrote:
>> How about no operator at all? It won't be as cool to read, but
>> consider, the arguments are text and text, not involving any hstore type
>> at all, so whatever operator you choose is in practice blocked from
>> everyone everywhere. No one could e
Peter Eisentraut writes:
> How about no operator at all? It won't be as cool to read, but
> consider, the arguments are text and text, not involving any hstore type
> at all, so whatever operator you choose is in practice blocked from
> everyone everywhere. No one could ever implement another ke
Peter Eisentraut writes:
>>> Btw., the SQL standard also defines -> for something else, so if you
>>> wanted to be really visionary, you could deprecate that one as an
>>> operator at the same time.
>>
>> Ouch. What does it define it to mean?
> Similar to C: Dereferencing a reference and access
On tis, 2010-06-08 at 15:38 -0400, Robert Haas wrote:
> I'm happy to do whatever the consensus is. I thought it would be
> easier to remember if the two operators were spelled at least somewhat
> similarly, but I just work here.
How about no operator at all? It won't be as cool to read, but
cons
On fre, 2010-06-11 at 07:10 -0400, Robert Haas wrote:
> On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut wrote:
> > On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
> >> > Perhaps
> >> > ->
> >>
> >> That's already in use to mean something else.
> >
> > Btw., the SQL standard also defines ->
On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut wrote:
> On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
>> > Perhaps
>> > ->
>>
>> That's already in use to mean something else.
>
> Btw., the SQL standard also defines -> for something else, so if you
> wanted to be really visionary, you co
On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
> > Perhaps
> > ->
>
> That's already in use to mean something else.
Btw., the SQL standard also defines -> for something else, so if you
wanted to be really visionary, you could deprecate that one as an
operator at the same time.
--
Sent v
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler wrote:
> On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>
>>> I actually like :> pretty well. It looks more like =>, and has nice
>>> correspondence to := for named function params.
>>
>> Colon was removed from the set of allowed operator-name charac
> "Tom" == Tom Lane writes:
>> While I don't like the inconsistency between ==> or whatever and
>> the use of => in type input and output, I regard the text
>> representation as being much harder to change safely, since client
>> code will be parsing it. In this case the inconsistency see
On Jun 9, 2010, at 10:33 AM, Robert Haas wrote:
> Well, that doesn't look much like an arrow, at least not to me...
It's a pointer, though. Not in the C sense, of course. But I often use » for
"read more" style links in HTML. Its the same idea: move from this to that.
Anyway, for comparison's p
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler wrote:
> On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>
>>> I actually like :> pretty well. It looks more like =>, and has nice
>>> correspondence to := for named function params.
>>
>> Colon was removed from the set of allowed operator-name charac
On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>> I actually like :> pretty well. It looks more like =>, and has nice
>> correspondence to := for named function params.
>
> Colon was removed from the set of allowed operator-name characters years
> ago. There are conflicts with various usages (ecp
"David E. Wheeler" writes:
> I actually like :> pretty well. It looks more like =>, and has nice
> correspondence to := for named function params.
Colon was removed from the set of allowed operator-name characters years
ago. There are conflicts with various usages (ecpg & psql variables).
This
On Wed, Jun 9, 2010 at 12:54 PM, David E. Wheeler wrote:
>> Perhaps it would be sane to make hstore_in accept either => or ==>, but
>> not change hstore_out (for now)?
>
> +1
Anyone want to take a crack at coding that? I took a brief look at
the code but it looked a bit intimidating at first gla
On Jun 9, 2010, at 9:30 AM, Tom Lane wrote:
> Andrew Gierth writes:
>> I'd really like to find a better operator name than ==>. But I'm not
>> convinced one exists.
>
> I agree.
+1
No one liked my suggestion of ~> ? Too similar to -> ? Other ideas:
'foo' :> 'bar'
'foo' @> 'bar'
'foo'
Andrew Gierth writes:
> I'd really like to find a better operator name than ==>. But I'm not
> convinced one exists.
I agree.
> While I don't like the inconsistency between ==> or whatever and the use
> of => in type input and output, I regard the text representation as being
> much harder to ch
> "Robert" == Robert Haas writes:
Robert> I don't think so, either. The most someone might want to do
Robert> is make ==> work wherever => does now, but I wouldn't want to
Robert> start monkeying with that without some input from Andrew
Robert> Gierth; and I don't think it's a stop-ship
Robert Haas writes:
> + if (!strcmp(oprName, "=>"))
BTW, project standard is to spell that like
> + if (strcmp(oprName, "=>") == 0)
The other way looks confusingly like a "not equal" test.
> + (errmsg("The use of => as an operator name is
> deprecated and m
On Wed, Jun 9, 2010 at 9:06 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>>> What about a WARNING at CREATE OPERATOR time?
>>
>> That's what the patch I sent already does.
>
> Great :)
> I read comments in the email instead of the commit…
>
>> I'm not following this part.
>
> I'm wondering i
Robert Haas writes:
>> What about a WARNING at CREATE OPERATOR time?
>
> That's what the patch I sent already does.
Great :)
I read comments in the email instead of the commit…
> I'm not following this part.
I'm wondering if deprecating => as an SQL operator, we should too
deprecate its usage i
On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine wrote:
> Greg Stark writes:
>> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
>>> I believe that the consensus was mostly in favor of deprecating => as
>>> an operator name, with the intent to abolish it completely in a future
>>> release. At
Greg Stark writes:
> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to implement ==> as an alternative
>> operato
On Wed, Jun 9, 2010 at 6:41 AM, Greg Stark wrote:
> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to implement =
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
> I believe that the consensus was mostly in favor of deprecating => as
> an operator name, with the intent to abolish it completely in a future
> release. Attached is a patch to implement ==> as an alternative
> operator name for hstore, and to
2010/6/8 Tom Lane :
> Pavel Stehule writes:
>> p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
>
> Really? And replaced with what? And why wouldn't the replacement use
> the same operator names?
>
We talked about integrated hash tables support.
regards
Pavel
>
On Jun 8, 2010, at 12:34 PM, Merlin Moncure wrote:
> hm. any chance of a shorter operator, like '#'? I kinda agree that
> hstore_in and the operator don't have to be the same, but requiring
> three letter token for the two most high traffic operations w/hstore
> seems off to me.
>
> # is curre
On Jun 8, 2010, at 16:17 , Robert Haas wrote:
>> (That's enough bikeshedding for me.)
>
> Test first, then post? :-)
What? :) If I was productively contributing, I wouldn't be bikeshedding, now
would I?
Michael Glaesemann
grzm seespotcode net
--
Sent via pgsql-hackers mailing list (pgs
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
> On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure wrote:
>> hm. any chance of a shorter operator, like '#'? I kinda agree that
>> hstore_in and the operator don't have to be the same, but requiring
>> three letter token for the two most high traffi
On Tue, Jun 8, 2010 at 3:56 PM, Michael Glaesemann wrote:
> On Jun 8, 2010, at 15:38 , Robert Haas wrote:
>> On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure wrote:
>>> hm. any chance of a shorter operator, like '#'? I kinda agree that
>>> hstore_in and the operator don't have to be the same, bu
Tom Lane wrote:
Pavel Stehule writes:
p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
Really? And replaced with what? And why wouldn't the replacement use
the same operator names?
Yeah. I'll be looking for throats to cut if
Pavel Stehule writes:
> p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
Really? And replaced with what? And why wouldn't the replacement use
the same operator names?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
2010/6/8 Merlin Moncure :
> On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to implement ==> as an alternative
>> o
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure wrote:
> On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to impleme
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas wrote:
> I believe that the consensus was mostly in favor of deprecating => as
> an operator name, with the intent to abolish it completely in a future
> release. Attached is a patch to implement ==> as an alternative
> operator name for hstore, and to
I believe that the consensus was mostly in favor of deprecating => as
an operator name, with the intent to abolish it completely in a future
release. Attached is a patch to implement ==> as an alternative
operator name for hstore, and to make the backend throw a warning when
=> is used as an opera
94 matches
Mail list logo
