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.
Yeah, I
On Fri, Jul 2, 2010 at 12:36 PM, David E. Wheeler da...@kineticode.com 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
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 undocumented
On Fri, Jul 2, 2010 at 2:39 PM, David E. Wheeler da...@kineticode.com 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 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
On Fri, Jul 2, 2010 at 4:43 PM, David E. Wheeler da...@kineticode.com 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
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 hstore
David E. Wheeler da...@kineticode.com 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
On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com 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?
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane t...@sss.pgh.pa.us 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.
On Fri, Jul 2, 2010 at 5:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Okay, I'm confused. This patch removed an operator named %, which AFAIK
was not controversial. The problematic
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
slice(),
Josh Berkus j...@agliodbs.com 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
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
On Mon, Jun 21, 2010 at 1:37 PM, David E. Wheeler da...@kineticode.com 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
David E. Wheeler da...@kineticode.com 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 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
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 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
--
Sent via
On Fri, Jun 18, 2010 at 6:26 PM, David E. Wheeler da...@kineticode.com 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:
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? And,
On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler da...@kineticode.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
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 correlates:
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 better idea.)
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 Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus j...@agliodbs.com 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
On 6/17/10 1:40 PM, Robert Haas wrote:
On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus j...@agliodbs.com 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
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 Thu, Jun 17, 2010 at 4:50 PM, Josh Berkus j...@agliodbs.com wrote:
On 6/17/10 1:40 PM, Robert Haas wrote:
On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus j...@agliodbs.com wrote:
Since there are no other votes for that option (or, indeed, any other
option), I'm going to go with my original
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
Josh Berkus j...@agliodbs.com 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
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 differentiator.
%!
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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 %.
On Thu, Jun 17, 2010 at 11:04 PM, Andrew Dunstan and...@dunslane.net 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
On Tue, Jun 15, 2010 at 10:55 PM, David E. Wheeler da...@kineticode.com 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
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 argument
Robert Haas robertmh...@gmail.com 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
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
David E. Wheeler da...@kineticode.com 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
On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
and...@tao11.riddles.org.uk 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
On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:
On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
and...@tao11.riddles.org.uk 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
On Tue, Jun 15, 2010 at 9:04 PM, David E. Wheeler da...@kineticode.com wrote:
On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:
On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
I'm happy with deprecating the first two = in favour of hstore() if
that is in line
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 Sat, Jun 12, 2010 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com 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[]
Tom == Tom Lane t...@sss.pgh.pa.us 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[]
On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@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
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[]yields
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 a
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 removed)
David E. Wheeler da...@kineticode.com 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
David E. Wheeler da...@kineticode.com 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.
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 to
On Jun 12, 2010, at 10:21 AM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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,
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 via
On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut pete...@gmx.net 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
On fre, 2010-06-11 at 07:10 -0400, Robert Haas wrote:
On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut pete...@gmx.net 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
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
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
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 ever
David E. Wheeler da...@kineticode.com 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
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
--
Sent via
On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
Joseph Adams joeyadams3.14...@gmail.com 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')
On Fri, Jun 11, 2010 at 5:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joseph Adams joeyadams3.14...@gmail.com 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
2010/6/8 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Jun 9, 2010 at 6:41 AM, Greg Stark gsst...@mit.edu wrote:
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com 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.
Greg Stark gsst...@mit.edu writes:
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com 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 Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Greg Stark gsst...@mit.edu writes:
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com wrote:
I believe that the consensus was mostly in favor of deprecating = as
an operator name, with the intent to
Robert Haas robertmh...@gmail.com 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
On Wed, Jun 9, 2010 at 9:06 AM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Robert == Robert Haas robertmh...@gmail.com 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
Andrew Gierth and...@tao11.riddles.org.uk 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
On Jun 9, 2010, at 9:30 AM, Tom Lane wrote:
Andrew Gierth and...@tao11.riddles.org.uk 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' @
On Wed, Jun 9, 2010 at 12:54 PM, David E. Wheeler da...@kineticode.com 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
David E. Wheeler da...@kineticode.com 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
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 (ecpg psql
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler da...@kineticode.com 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
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
Tom == Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler da...@kineticode.com 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
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
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com 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
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com 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.
2010/6/8 Merlin Moncure mmonc...@gmail.com:
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com 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
Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com 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
On Tue, Jun 8, 2010 at 3:56 PM, Michael Glaesemann g...@seespotcode.net wrote:
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure mmonc...@gmail.com wrote:
hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure mmonc...@gmail.com 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
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
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 currently
94 matches
Mail list logo
