hstore ==> and deprecate =>
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 operator name.
One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Attachments:
hstore_op.patchapplication/octet-stream; name=hstore_op.patchDownload
diff --git a/contrib/hstore/expected/hstore.out b/contrib/hstore/expected/hstore.out
index 34db7f5..58325d7 100644
--- a/contrib/hstore/expected/hstore.out
+++ b/contrib/hstore/expected/hstore.out
@@ -712,137 +712,137 @@ select pg_column_size(''::hstore || 'aa=>1, b=>2'::hstore)
t
(1 row)
--- =>
-select 'a=>g, b=>c'::hstore || ( 'asd'=>'gf' );
+-- ==>
+select 'a=>g, b=>c'::hstore || ( 'asd'==>'gf' );
?column?
---------------------------------
"a"=>"g", "b"=>"c", "asd"=>"gf"
(1 row)
-select 'a=>g, b=>c'::hstore || ( 'b'=>'gf' );
+select 'a=>g, b=>c'::hstore || ( 'b'==>'gf' );
?column?
---------------------
"a"=>"g", "b"=>"gf"
(1 row)
-select 'a=>g, b=>c'::hstore || ( 'b'=>'NULL' );
+select 'a=>g, b=>c'::hstore || ( 'b'==>'NULL' );
?column?
-----------------------
"a"=>"g", "b"=>"NULL"
(1 row)
-select 'a=>g, b=>c'::hstore || ( 'b'=>NULL );
+select 'a=>g, b=>c'::hstore || ( 'b'==>NULL );
?column?
---------------------
"a"=>"g", "b"=>NULL
(1 row)
-select ('a=>g, b=>c'::hstore || ( NULL=>'b' )) is null;
+select ('a=>g, b=>c'::hstore || ( NULL==>'b' )) is null;
?column?
----------
t
(1 row)
-select pg_column_size(('b'=>'gf'))
+select pg_column_size(('b'==>'gf'))
= pg_column_size('b=>gf'::hstore);
?column?
----------
t
(1 row)
-select pg_column_size('a=>g, b=>c'::hstore || ('b'=>'gf'))
+select pg_column_size('a=>g, b=>c'::hstore || ('b'==>'gf'))
= pg_column_size('a=>g, b=>gf'::hstore);
?column?
----------
t
(1 row)
--- => arrays
-select ARRAY['a','b','asd'] => ARRAY['g','h','i'];
+-- ==> arrays
+select ARRAY['a','b','asd'] ==> ARRAY['g','h','i'];
?column?
--------------------------------
"a"=>"g", "b"=>"h", "asd"=>"i"
(1 row)
-select ARRAY['a','b','asd'] => ARRAY['g','h',NULL];
+select ARRAY['a','b','asd'] ==> ARRAY['g','h',NULL];
?column?
---------------------------------
"a"=>"g", "b"=>"h", "asd"=>NULL
(1 row)
-select ARRAY['z','y','x'] => ARRAY['1','2','3'];
+select ARRAY['z','y','x'] ==> ARRAY['1','2','3'];
?column?
------------------------------
"x"=>"3", "y"=>"2", "z"=>"1"
(1 row)
-select ARRAY['aaa','bb','c','d'] => ARRAY[null::text,null,null,null];
+select ARRAY['aaa','bb','c','d'] ==> ARRAY[null::text,null,null,null];
?column?
-----------------------------------------------
"c"=>NULL, "d"=>NULL, "bb"=>NULL, "aaa"=>NULL
(1 row)
-select ARRAY['aaa','bb','c','d'] => null;
+select ARRAY['aaa','bb','c','d'] ==> null;
?column?
-----------------------------------------------
"c"=>NULL, "d"=>NULL, "bb"=>NULL, "aaa"=>NULL
(1 row)
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['g','h','i'];
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['g','h','i'];
?column?
----------
(1 row)
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'];
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b'];
?column?
--------------------
"b"=>"2", "c"=>"3"
(1 row)
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['aa','b'];
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['aa','b'];
?column?
---------------------
"b"=>"2", "aa"=>"1"
(1 row)
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'];
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b','aa'];
?column?
-------------------------------
"b"=>"2", "c"=>"3", "aa"=>"1"
(1 row)
-select quote_literal('{}'::text[] => '{}'::text[]);
+select quote_literal('{}'::text[] ==> '{}'::text[]);
quote_literal
---------------
''
(1 row)
-select quote_literal('{}'::text[] => null);
+select quote_literal('{}'::text[] ==> null);
quote_literal
---------------
''
(1 row)
-select ARRAY['a'] => '{}'::text[]; -- error
+select ARRAY['a'] ==> '{}'::text[]; -- error
ERROR: arrays must have same bounds
-select '{}'::text[] => ARRAY['a']; -- error
+select '{}'::text[] ==> ARRAY['a']; -- error
ERROR: arrays must have same bounds
-select pg_column_size(ARRAY['a','b','asd'] => ARRAY['g','h','i'])
+select pg_column_size(ARRAY['a','b','asd'] ==> ARRAY['g','h','i'])
= pg_column_size('a=>g, b=>h, asd=>i'::hstore);
?column?
----------
t
(1 row)
-select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'])
+select pg_column_size(hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b'])
= pg_column_size('b=>2, c=>3'::hstore);
?column?
----------
t
(1 row)
-select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'])
+select pg_column_size(hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b','aa'])
= pg_column_size('aa=>1, b=>2, c=>3'::hstore);
?column?
----------
@@ -948,45 +948,45 @@ select pg_column_size(hstore(v))
t
(1 row)
-select populate_record(v, ('c' => '3.45')) from testhstore1 v;
+select populate_record(v, ('c' ==> '3.45')) from testhstore1 v;
populate_record
------------------
(1,foo,3.45,3,0)
(1 row)
-select populate_record(v, ('d' => '3.45')) from testhstore1 v;
+select populate_record(v, ('d' ==> '3.45')) from testhstore1 v;
populate_record
--------------------
(1,foo,1.2,3.45,0)
(1 row)
-select populate_record(v, ('e' => '123')) from testhstore1 v;
+select populate_record(v, ('e' ==> '123')) from testhstore1 v;
populate_record
-------------------
(1,foo,1.2,3,123)
(1 row)
-select populate_record(v, ('e' => null)) from testhstore1 v;
+select populate_record(v, ('e' ==> null)) from testhstore1 v;
ERROR: domain hstestdom1 does not allow null values
-select populate_record(v, ('c' => null)) from testhstore1 v;
+select populate_record(v, ('c' ==> null)) from testhstore1 v;
populate_record
-----------------
(1,foo,,3,0)
(1 row)
-select populate_record(v, ('b' => 'foo') || ('a' => '123')) from testhstore1 v;
+select populate_record(v, ('b' ==> 'foo') || ('a' ==> '123')) from testhstore1 v;
populate_record
-------------------
(123,foo,1.2,3,0)
(1 row)
-select populate_record(v, ('b' => 'foo') || ('e' => null)) from testhstore0 v;
+select populate_record(v, ('b' ==> 'foo') || ('e' ==> null)) from testhstore0 v;
populate_record
-----------------
(1,foo,1.2,3)
(1 row)
-select populate_record(v, ('b' => 'foo') || ('e' => null)) from testhstore1 v;
+select populate_record(v, ('b' ==> 'foo') || ('e' ==> null)) from testhstore1 v;
ERROR: domain hstestdom1 does not allow null values
select populate_record(v, '') from testhstore0 v;
populate_record
@@ -1000,9 +1000,9 @@ select populate_record(v, '') from testhstore1 v;
(1,foo,1.2,3,0)
(1 row)
-select populate_record(null::testhstore1, ('c' => '3.45') || ('a' => '123'));
+select populate_record(null::testhstore1, ('c' ==> '3.45') || ('a' ==> '123'));
ERROR: domain hstestdom1 does not allow null values
-select populate_record(null::testhstore1, ('c' => '3.45') || ('e' => '123'));
+select populate_record(null::testhstore1, ('c' ==> '3.45') || ('e' ==> '123'));
populate_record
-----------------
(,,3.45,,123)
@@ -1016,45 +1016,45 @@ select populate_record(null::testhstore0, '');
select populate_record(null::testhstore1, '');
ERROR: domain hstestdom1 does not allow null values
-select v #= ('c' => '3.45') from testhstore1 v;
+select v #= ('c' ==> '3.45') from testhstore1 v;
?column?
------------------
(1,foo,3.45,3,0)
(1 row)
-select v #= ('d' => '3.45') from testhstore1 v;
+select v #= ('d' ==> '3.45') from testhstore1 v;
?column?
--------------------
(1,foo,1.2,3.45,0)
(1 row)
-select v #= ('e' => '123') from testhstore1 v;
+select v #= ('e' ==> '123') from testhstore1 v;
?column?
-------------------
(1,foo,1.2,3,123)
(1 row)
-select v #= ('c' => null) from testhstore1 v;
+select v #= ('c' ==> null) from testhstore1 v;
?column?
--------------
(1,foo,,3,0)
(1 row)
-select v #= ('e' => null) from testhstore0 v;
+select v #= ('e' ==> null) from testhstore0 v;
?column?
---------------
(1,foo,1.2,3)
(1 row)
-select v #= ('e' => null) from testhstore1 v;
+select v #= ('e' ==> null) from testhstore1 v;
ERROR: domain hstestdom1 does not allow null values
-select v #= (('b' => 'foo') || ('a' => '123')) from testhstore1 v;
+select v #= (('b' ==> 'foo') || ('a' ==> '123')) from testhstore1 v;
?column?
-------------------
(123,foo,1.2,3,0)
(1 row)
-select v #= (('b' => 'foo') || ('e' => '123')) from testhstore1 v;
+select v #= (('b' ==> 'foo') || ('e' ==> '123')) from testhstore1 v;
?column?
-------------------
(1,foo,1.2,3,123)
@@ -1072,9 +1072,9 @@ select v #= hstore '' from testhstore1 v;
(1,foo,1.2,3,0)
(1 row)
-select null::testhstore1 #= (('c' => '3.45') || ('a' => '123'));
+select null::testhstore1 #= (('c' ==> '3.45') || ('a' ==> '123'));
ERROR: domain hstestdom1 does not allow null values
-select null::testhstore1 #= (('c' => '3.45') || ('e' => '123'));
+select null::testhstore1 #= (('c' ==> '3.45') || ('e' ==> '123'));
?column?
---------------
(,,3.45,,123)
diff --git a/contrib/hstore/hstore.sql.in b/contrib/hstore/hstore.sql.in
index 972557a..61e048f 100644
--- a/contrib/hstore/hstore.sql.in
+++ b/contrib/hstore/hstore.sql.in
@@ -66,6 +66,13 @@ RETURNS hstore
AS 'MODULE_PATHNAME','hstore_slice_to_hstore'
LANGUAGE C STRICT IMMUTABLE;
+CREATE OPERATOR ==> (
+ LEFTARG = hstore,
+ RIGHTARG = text[],
+ PROCEDURE = slice_hstore
+);
+
+-- Deprecated. For backward compatibility.
CREATE OPERATOR => (
LEFTARG = hstore,
RIGHTARG = text[],
@@ -227,6 +234,13 @@ RETURNS hstore
AS 'MODULE_PATHNAME','hstore_from_text'
LANGUAGE C IMMUTABLE; -- not STRICT; needs to allow (key,NULL)
+CREATE OPERATOR ==> (
+ LEFTARG = text,
+ RIGHTARG = text,
+ PROCEDURE = hstore
+);
+
+-- Deprecated. For backward compatibility.
CREATE OPERATOR => (
LEFTARG = text,
RIGHTARG = text,
@@ -238,6 +252,13 @@ RETURNS hstore
AS 'MODULE_PATHNAME', 'hstore_from_arrays'
LANGUAGE C IMMUTABLE; -- not STRICT; allows (keys,null)
+CREATE OPERATOR ==> (
+ LEFTARG = text[],
+ RIGHTARG = text[],
+ PROCEDURE = hstore
+);
+
+-- Deprecated. For backward compatibility.
CREATE OPERATOR => (
LEFTARG = text[],
RIGHTARG = text[],
diff --git a/contrib/hstore/sql/hstore.sql b/contrib/hstore/sql/hstore.sql
index a88ff1d..68f9033 100644
--- a/contrib/hstore/sql/hstore.sql
+++ b/contrib/hstore/sql/hstore.sql
@@ -160,36 +160,36 @@ select pg_column_size('aa=>1, b=>2'::hstore || ''::hstore)
select pg_column_size(''::hstore || 'aa=>1, b=>2'::hstore)
= pg_column_size('aa=>1, b=>2'::hstore);
--- =>
-select 'a=>g, b=>c'::hstore || ( 'asd'=>'gf' );
-select 'a=>g, b=>c'::hstore || ( 'b'=>'gf' );
-select 'a=>g, b=>c'::hstore || ( 'b'=>'NULL' );
-select 'a=>g, b=>c'::hstore || ( 'b'=>NULL );
-select ('a=>g, b=>c'::hstore || ( NULL=>'b' )) is null;
-select pg_column_size(('b'=>'gf'))
+-- ==>
+select 'a=>g, b=>c'::hstore || ( 'asd'==>'gf' );
+select 'a=>g, b=>c'::hstore || ( 'b'==>'gf' );
+select 'a=>g, b=>c'::hstore || ( 'b'==>'NULL' );
+select 'a=>g, b=>c'::hstore || ( 'b'==>NULL );
+select ('a=>g, b=>c'::hstore || ( NULL==>'b' )) is null;
+select pg_column_size(('b'==>'gf'))
= pg_column_size('b=>gf'::hstore);
-select pg_column_size('a=>g, b=>c'::hstore || ('b'=>'gf'))
+select pg_column_size('a=>g, b=>c'::hstore || ('b'==>'gf'))
= pg_column_size('a=>g, b=>gf'::hstore);
--- => arrays
-select ARRAY['a','b','asd'] => ARRAY['g','h','i'];
-select ARRAY['a','b','asd'] => ARRAY['g','h',NULL];
-select ARRAY['z','y','x'] => ARRAY['1','2','3'];
-select ARRAY['aaa','bb','c','d'] => ARRAY[null::text,null,null,null];
-select ARRAY['aaa','bb','c','d'] => null;
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['g','h','i'];
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'];
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['aa','b'];
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'];
-select quote_literal('{}'::text[] => '{}'::text[]);
-select quote_literal('{}'::text[] => null);
-select ARRAY['a'] => '{}'::text[]; -- error
-select '{}'::text[] => ARRAY['a']; -- error
-select pg_column_size(ARRAY['a','b','asd'] => ARRAY['g','h','i'])
+-- ==> arrays
+select ARRAY['a','b','asd'] ==> ARRAY['g','h','i'];
+select ARRAY['a','b','asd'] ==> ARRAY['g','h',NULL];
+select ARRAY['z','y','x'] ==> ARRAY['1','2','3'];
+select ARRAY['aaa','bb','c','d'] ==> ARRAY[null::text,null,null,null];
+select ARRAY['aaa','bb','c','d'] ==> null;
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['g','h','i'];
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b'];
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['aa','b'];
+select hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b','aa'];
+select quote_literal('{}'::text[] ==> '{}'::text[]);
+select quote_literal('{}'::text[] ==> null);
+select ARRAY['a'] ==> '{}'::text[]; -- error
+select '{}'::text[] ==> ARRAY['a']; -- error
+select pg_column_size(ARRAY['a','b','asd'] ==> ARRAY['g','h','i'])
= pg_column_size('a=>g, b=>h, asd=>i'::hstore);
-select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'])
+select pg_column_size(hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b'])
= pg_column_size('b=>2, c=>3'::hstore);
-select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'])
+select pg_column_size(hstore 'aa=>1, b=>2, c=>3' ==> ARRAY['c','b','aa'])
= pg_column_size('aa=>1, b=>2, c=>3'::hstore);
-- array input
@@ -221,32 +221,32 @@ select hstore(null::testhstore1);
select pg_column_size(hstore(v))
= pg_column_size('a=>1, b=>"foo", c=>"1.2", d=>"3", e=>"0"'::hstore)
from testhstore1 v;
-select populate_record(v, ('c' => '3.45')) from testhstore1 v;
-select populate_record(v, ('d' => '3.45')) from testhstore1 v;
-select populate_record(v, ('e' => '123')) from testhstore1 v;
-select populate_record(v, ('e' => null)) from testhstore1 v;
-select populate_record(v, ('c' => null)) from testhstore1 v;
-select populate_record(v, ('b' => 'foo') || ('a' => '123')) from testhstore1 v;
-select populate_record(v, ('b' => 'foo') || ('e' => null)) from testhstore0 v;
-select populate_record(v, ('b' => 'foo') || ('e' => null)) from testhstore1 v;
+select populate_record(v, ('c' ==> '3.45')) from testhstore1 v;
+select populate_record(v, ('d' ==> '3.45')) from testhstore1 v;
+select populate_record(v, ('e' ==> '123')) from testhstore1 v;
+select populate_record(v, ('e' ==> null)) from testhstore1 v;
+select populate_record(v, ('c' ==> null)) from testhstore1 v;
+select populate_record(v, ('b' ==> 'foo') || ('a' ==> '123')) from testhstore1 v;
+select populate_record(v, ('b' ==> 'foo') || ('e' ==> null)) from testhstore0 v;
+select populate_record(v, ('b' ==> 'foo') || ('e' ==> null)) from testhstore1 v;
select populate_record(v, '') from testhstore0 v;
select populate_record(v, '') from testhstore1 v;
-select populate_record(null::testhstore1, ('c' => '3.45') || ('a' => '123'));
-select populate_record(null::testhstore1, ('c' => '3.45') || ('e' => '123'));
+select populate_record(null::testhstore1, ('c' ==> '3.45') || ('a' ==> '123'));
+select populate_record(null::testhstore1, ('c' ==> '3.45') || ('e' ==> '123'));
select populate_record(null::testhstore0, '');
select populate_record(null::testhstore1, '');
-select v #= ('c' => '3.45') from testhstore1 v;
-select v #= ('d' => '3.45') from testhstore1 v;
-select v #= ('e' => '123') from testhstore1 v;
-select v #= ('c' => null) from testhstore1 v;
-select v #= ('e' => null) from testhstore0 v;
-select v #= ('e' => null) from testhstore1 v;
-select v #= (('b' => 'foo') || ('a' => '123')) from testhstore1 v;
-select v #= (('b' => 'foo') || ('e' => '123')) from testhstore1 v;
+select v #= ('c' ==> '3.45') from testhstore1 v;
+select v #= ('d' ==> '3.45') from testhstore1 v;
+select v #= ('e' ==> '123') from testhstore1 v;
+select v #= ('c' ==> null) from testhstore1 v;
+select v #= ('e' ==> null) from testhstore0 v;
+select v #= ('e' ==> null) from testhstore1 v;
+select v #= (('b' ==> 'foo') || ('a' ==> '123')) from testhstore1 v;
+select v #= (('b' ==> 'foo') || ('e' ==> '123')) from testhstore1 v;
select v #= hstore '' from testhstore0 v;
select v #= hstore '' from testhstore1 v;
-select null::testhstore1 #= (('c' => '3.45') || ('a' => '123'));
-select null::testhstore1 #= (('c' => '3.45') || ('e' => '123'));
+select null::testhstore1 #= (('c' ==> '3.45') || ('a' ==> '123'));
+select null::testhstore1 #= (('c' ==> '3.45') || ('e' ==> '123'));
select null::testhstore0 #= hstore '';
select null::testhstore1 #= hstore '';
select v #= h from testhstore1 v, (values (hstore 'a=>123',1),('b=>foo,c=>3.21',2),('a=>null',3),('e=>123',4),('f=>blah',5)) x(h,i) order by i;
diff --git a/contrib/hstore/uninstall_hstore.sql b/contrib/hstore/uninstall_hstore.sql
index 27463b9..a273bf6 100644
--- a/contrib/hstore/uninstall_hstore.sql
+++ b/contrib/hstore/uninstall_hstore.sql
@@ -21,6 +21,9 @@ DROP OPERATOR @> ( hstore, hstore );
DROP OPERATOR <@ ( hstore, hstore );
DROP OPERATOR @ ( hstore, hstore );
DROP OPERATOR ~ ( hstore, hstore );
+DROP OPERATOR ==> ( text, text );
+DROP OPERATOR ==> ( text[], text[] );
+DROP OPERATOR ==> ( hstore, text[] );
DROP OPERATOR => ( text, text );
DROP OPERATOR => ( text[], text[] );
DROP OPERATOR => ( hstore, text[] );
diff --git a/src/backend/commands/operatorcmds.c b/src/backend/commands/operatorcmds.c
index 9c07cf3..83d68f8 100644
--- a/src/backend/commands/operatorcmds.c
+++ b/src/backend/commands/operatorcmds.c
@@ -88,6 +88,16 @@ DefineOperator(List *names, List *parameters)
/* Convert list of names to a name and namespace */
oprNamespace = QualifiedNameGetCreationNamespace(names, &oprName);
+ /*
+ * The SQL standard committee has decided that => should be used for
+ * named parameters; therefore, a future release of PostgreSQL will
+ * no longer allow this to be used as the name of a user-defined
+ * operator. For now, we just emit a warning.
+ */
+ if (!strcmp(oprName, "=>"))
+ ereport(WARNING,
+ (errmsg("The use of => as an operator name is deprecated and may be disallowed in a future release.")));
+
/* Check we have creation rights in target namespace */
aclresult = pg_namespace_aclcheck(oprNamespace, GetUserId(), ACL_CREATE);
if (aclresult != ACLCHECK_OK)
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas@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 hstore, and to make the backend throw a warning when
=> is used as an operator name.One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php
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 used for bitwise xor/geo
merlin
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas@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 hstore, and to make the backend throw a warning when
=> is used as an operator name.One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php
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 used for bitwise xor/geo
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
2010/6/8 Merlin Moncure <mmoncure@gmail.com>:
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas <robertmhaas@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 hstore, and to make the backend throw a warning when
=> is used as an operator name.One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.http://archives.postgresql.org/pgsql-hackers/2010-05/msg01501.php
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.
I am for Robert's proposal - ===> is one char longer - but
significantly readable
Regards
Pavel
p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
Show quoted text
# is currently used for bitwise xor/geo
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel Stehule <pavel.stehule@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
Tom Lane wrote:
Pavel Stehule <pavel.stehule@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 looking for throats to cut if that happens. I have several
apps that use it extensively. If anything, I want it brought into core -
it has wide ranging usefulness.
cheers
andrew
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure@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 high traffic operations w/hstore
seems off to me.# is currently used for bitwise xor/geo
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.
Perhaps
->
Would a colon work?
(That's enough bikeshedding for me.)
Michael Glaesemann
grzm seespotcode net
On Tue, Jun 8, 2010 at 3:56 PM, Michael Glaesemann <grzm@seespotcode.net> wrote:
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure <mmoncure@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 high traffic operations w/hstore
seems off to me.# is currently used for bitwise xor/geo
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.Perhaps
->
That's already in use to mean something else.
Would a colon work?
Nope.
ERROR: syntax error at or near ":"
(That's enough bikeshedding for me.)
Test first, then post? :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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
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 used for bitwise xor/geo
Not at all the same.
What about ~> ?
Best,
David
2010/6/8 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@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 tables support.
regards
Pavel
Show quoted text
regards, tom lane
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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 hstore, and to make the backend throw a warning when
=> is used as an operator name.
I don't think we can throw warnings for DML except in the most dire
circumstances. In an OLTP system with high throughput a warning would
fill the logs quickly, effectively making it impossible to use the
syntax being warned about. If we're willing to do that we would just
use an ERROR anyways which I don't think we're willing to do. People
might need a transition period when they still use => because they
need to write code which will work with either old or new versions.
One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.
I hate these kinds of inconsistencies. I would prefer both operators
be consistent.
--
greg
On Wed, Jun 9, 2010 at 6:41 AM, Greg Stark <gsstark@mit.edu> wrote:
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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 hstore, and to make the backend throw a warning when
=> is used as an operator name.I don't think we can throw warnings for DML except in the most dire
circumstances.
The patch doesn't.
One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.I hate these kinds of inconsistencies. I would prefer both operators
be consistent.
Sure, me too, but I think this is the best we can do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Greg Stark <gsstark@mit.edu> writes:
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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 hstore, and to make the backend throw a warning when
=> is used as an operator name.I don't think we can throw warnings for DML except in the most dire
circumstances.
What about a WARNING at CREATE OPERATOR time?
One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.I hate these kinds of inconsistencies. I would prefer both operators
be consistent.
dim=# select 'foo' => 'bar', 'foo => bar'::hstore;
?column? | hstore
--------------+--------------
"foo"=>"bar" | "foo"=>"bar"
(1 ligne)
Well it's not an operator in the second case, it's part of the input
"language" of the datatype. So consistency would be good enough if we
had both the legacy input syntax support and the new one, right?
Regards,
--
dim
On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:
Greg Stark <gsstark@mit.edu> writes:
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas <robertmhaas@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 hstore, and to make the backend throw a warning when
=> is used as an operator name.I don't think we can throw warnings for DML except in the most dire
circumstances.What about a WARNING at CREATE OPERATOR time?
That's what the patch I sent already does.
One wart is that => is used not only as a SQL-level operator, but also
by hstore_in() when interpreting hstore-type literals, and by
hstore_out() when generating them. My gut feeling is that we should
leave this part alone and only muck with the SQL operator, but perhaps
someone will care to argue the point.I hate these kinds of inconsistencies. I would prefer both operators
be consistent.dim=# select 'foo' => 'bar', 'foo => bar'::hstore;
?column? | hstore
--------------+--------------
"foo"=>"bar" | "foo"=>"bar"
(1 ligne)Well it's not an operator in the second case, it's part of the input
"language" of the datatype. So consistency would be good enough if we
had both the legacy input syntax support and the new one, right?
I'm not following this part.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Robert Haas <robertmhaas@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
deprecate its usage in input text for hstore. I don't think so.
--
Dimitri Fontaine
PostgreSQL DBA, Architecte
On Wed, Jun 9, 2010 at 9:06 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:
Robert Haas <robertmhaas@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
deprecate its usage in input text for hstore. I don't think so.
I don't think so, either. The most someone might want to do is make
==> work wherever => does now, but I wouldn't want to start monkeying
with that without some input from Andrew Gierth; and I don't think
it's a stop-ship issue for 9.0.
Unless there is more than one vote for some alternative other than
what I've done here (which so far there isn't), I'm going to add some
docs to this patch and commit it later today. Because the SQL
committee has standardized an incompatible syntax, there are no
perfect alternatives here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
"Robert" == Robert Haas <robertmhaas@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 stop-ship issue for 9.0.
I'd really like to find a better operator name than ==>. But I'm not
convinced one exists.
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 seems like a much smaller problem than changing the
text representation.
--
Andrew (irc:RhodiumToad)
Robert Haas <robertmhaas@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 deprecated and may be disallowed in a future release.")));
Also, this doesn't follow message style guidelines. Possibly better:
errmsg("=> is deprecated as an operator name"),
errdetail("This name may be disallowed altogether in future versions of PostgreSQL.")
regards, tom lane
Andrew Gierth <andrew@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 being
much harder to change safely, since client code will be parsing it. In this
case the inconsistency seems like a much smaller problem than changing the
text representation.
Perhaps it would be sane to make hstore_in accept either => or ==>, but
not change hstore_out (for now)?
regards, tom lane
On Jun 9, 2010, at 9:30 AM, Tom Lane wrote:
Andrew Gierth <andrew@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' @> 'bar'
'foo' #> 'bar'
'foo' &> 'bar'
'foo' *> 'bar'
'foo' +> 'bar'
'foo' > 'bar'
'bar' <= 'foo'
I actually like :> pretty well. It looks more like =>, and has nice correspondence to := for named function params.
Hey, why not Unicode?
'bar' ➡ 'foo'
;-)
Perhaps it would be sane to make hstore_in accept either => or ==>, but
not change hstore_out (for now)?
+1
David
On Wed, Jun 9, 2010 at 12:54 PM, David E. Wheeler <david@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 at first glance.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
"David E. Wheeler" <david@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 variables).
This is actually a place where the current := behavior could cause some
issues, though I'm not aware of any at the moment.
regards, tom lane
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 variables).
This is actually a place where the current := behavior could cause some
issues, though I'm not aware of any at the moment.
Oh, that's a shame.
In that case, how about:
'foo' >> 'bar'
Best,
David
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler <david@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 characters years
ago. There are conflicts with various usages (ecpg & psql variables).
This is actually a place where the current := behavior could cause some
issues, though I'm not aware of any at the moment.Oh, that's a shame.
In that case, how about:
'foo' >> 'bar'
Well, that doesn't look much like an arrow, at least not to me...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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 purpose:
'foo' ==> 'bar'
'foo' >> 'bar'
Pity about :>.
Best,
David
"Tom" == Tom Lane <tgl@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 seems like
a much smaller problem than changing the text representation.
Tom> Perhaps it would be sane to make hstore_in accept either => or
Tom> ==>, but not change hstore_out (for now)?
I'd be happy with that.
--
Andrew (irc:RhodiumToad)
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler <david@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 characters years
ago. There are conflicts with various usages (ecpg & psql variables).
This is actually a place where the current := behavior could cause some
issues, though I'm not aware of any at the moment.Oh, that's a shame.
In that case, how about:
'foo' >> 'bar'
+1
merlin
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.
On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut <peter_e@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 could deprecate that one as an
operator at the same time.
Ouch. What does it define it to mean?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On fre, 2010-06-11 at 07:10 -0400, Robert Haas wrote:
On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut <peter_e@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 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 accessing a member.
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
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 key/value
system that uses a similar interface. Or use the operator for anything
else involving strings.
Why not just write:
hstore('this', 'that')
hstore(key := 'this', value := 'that')
Peter Eisentraut <peter_e@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 accessing a member.
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 =>).
regards, tom lane
Peter Eisentraut <peter_e@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 implement another key/value
system that uses a similar interface. Or use the operator for anything
else involving strings.
Yeah, that's a good point. Maybe we should just deprecate the operator
altogether.
regards, tom lane
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 implement another key/value
system that uses a similar interface. Or use the operator for anything
else involving strings.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.
Best,
David
"David E. Wheeler" <david@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 inconsistent, ITYM? But yeah, then we would have no reason to
fiddle with hstore_in, which is good.
regards, tom lane
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
On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@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 implement another key/value
system that uses a similar interface. Or use the operator for anything
else involving strings.Yeah, that's a good point. Maybe we should just deprecate the operator
altogether.regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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('this' AS key, 'that' AS key2))
In my opinion, it's important to find a reasonably elegant way to
express hstore literals (rather than something like
hstore(hstore_kvp('key', 'this'), hstore_kvp('key2', 'that')) )
because something so basic shouldn't be so difficult to work with.
It'd be a bonus if there was a general form for arbitrary named
parameters that new functions could opt-in on (in particular,
json_object :-) ).
This type of function could be created by saying something like:
CREATE FUNCTION hstore(NAMED) RETURNS hstore AS ...
-- NAMED would be a new argtype
Also, if a user needs to name a field from a variable, perhaps there
should be a syntax that allows it, such as:
hstore(pg_deref(var) => 'this', pg_deref(var2) => 'that')
If implementing pg_deref would be problematic in general, perhaps it
could initially just be supported in keys of functions like this.
Only if we allow for functions with named parameters in this fashion
would I say +1 for deprecating the => operator from hstore without a
replacement operator like ==> .
Joey Adams
Joseph Adams <joeyadams3.14159@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')
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:
contrib_regression=# select hstore(row('this', 'that'));
hstore
----------------------------
"f1"=>"this", "f2"=>"that"
(1 row)
and the only thing lacking is an easy way to specify the column names
associated with the anonymous record type. Extending the ROW()
construct with AS labels as suggested above might be a reasonable way.
regards, tom lane
On Fri, Jun 11, 2010 at 5:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Joseph Adams <joeyadams3.14159@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')
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:contrib_regression=# select hstore(row('this', 'that'));
hstore
----------------------------
"f1"=>"this", "f2"=>"that"
(1 row)and the only thing lacking is an easy way to specify the column names
associated with the anonymous record type. Extending the ROW()
construct with AS labels as suggested above might be a reasonable way.
+1
A couple of people were just requesting that very thing (ROW/AS) on
the IRC channel today. row() is a pretty useful mechanism and it
would be nice to have it more defensible vs. table changes.
merlin
On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@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 accessing a member.
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)
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
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 => 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?
Hm, the last one seems to be more akin to
hstore - text yields hstore (key removed)
hstore - text[] yields hstore (keys in array removed)
hstore - hstore yields hstore (keys in hstore removed)
since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore.
Inspired by the already existing
hstore ?& text[] yields boolean (true if set of keys subset of array)
I suggest
hstore & text[]
as a replacement.
best regards,
Florian Pflug
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 function with any number of named params?
Best,
David
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 - text yields hstore (key removed)
hstore - text[] yields hstore (keys in array removed)
hstore - hstore yields hstore (keys in hstore removed)
Well, no, the keys aren't removed: you get back an hstore with only those keys (the lhs is unchanged).
since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore.
Inspired by the already existing
hstore ?& text[] yields boolean (true if set of keys subset of array)
I suggest
hstore & text[]
as a replacement.
Yes, agreed.
That just leaves
text[] => text[] yields hstore (with N elements)
Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an
hstore(text[], text[])
Best,
David
"David E. Wheeler" <david@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
hstore_from_record:
Is not the first one simply a function with any number of named params?
No, because the desire presumably would be to be able to use any set of
parameter names with that one function ... which absolutely flies in the
face of our current notion of what a parameter name means. You'd
essentially have to disable the ability to have function overloading.
(Which probably means it Ain't Happening.)
regards, tom lane
"David E. Wheeler" <david@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. So at this
point the proposal is:
* Leave the text => text operator alone for now, but deprecate it,
and document/recommend the underlying hstore(text,text) function
instead.
* Get rid of the new text[] => text[] operator altogether, and
provide/document only the underlying hstore(text[], text[])
function.
* Rename the new hstore => text[] operator to something else.
(I'm not quite sold on Florian's & proposal, but don't have a
better idea to offer offhand.)
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 revert
to calling it tconvert(). Can we retroactively add the alternate name
hstore() to previous versions, and suggest that people do that manually
in existing hstore installations?
regards, tom lane
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 revert
to calling it tconvert(). Can we retroactively add the alternate name
hstore() to previous versions, and suggest that people do that manually
in existing hstore installations?
In general, I don't think we make enough use of supplying
backward-compatible SQL scripts to fix things, so +1. Let's use the
object-relational features we have to make things easier for users.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
On Jun 12, 2010, at 10:21 AM, Tom Lane wrote:
"David E. Wheeler" <david@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. So at this
point the proposal is:* Leave the text => text operator alone for now, but deprecate it,
and document/recommend the underlying hstore(text,text) function
instead.* Get rid of the new text[] => text[] operator altogether, and
provide/document only the underlying hstore(text[], text[])
function.* Rename the new hstore => text[] operator to something else.
(I'm not quite sold on Florian's & proposal, but don't have a
better idea to offer offhand.)
+1
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 revert
to calling it tconvert(). Can we retroactively add the alternate name
hstore() to previous versions, and suggest that people do that manually
in existing hstore installations?
+1
Best,
David
On Sat, Jun 12, 2010 at 1:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David E. Wheeler" <david@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. So at this
point the proposal is:* Leave the text => text operator alone for now, but deprecate it,
and document/recommend the underlying hstore(text,text) function
instead.* Get rid of the new text[] => text[] operator altogether, and
provide/document only the underlying hstore(text[], text[])
function.* Rename the new hstore => text[] operator to something else.
(I'm not quite sold on Florian's & proposal, but don't have a
better idea to offer offhand.)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 revert
to calling it tconvert(). Can we retroactively add the alternate name
hstore() to previous versions, and suggest that people do that manually
in existing hstore installations?
Here's a patch that removes the text[] => text[] operator - as
suggested above - and instead documents hstore(text[], text[]).
Barring objections, I will commit this and then start looking at the
other portions of this proposal.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Attachments:
hstore_remove_array_constructor_arrow.patchapplication/octet-stream; name=hstore_remove_array_constructor_arrow.patchDownload
diff --git a/contrib/hstore/expected/hstore.out b/contrib/hstore/expected/hstore.out
index 34db7f5..6a26bc1 100644
--- a/contrib/hstore/expected/hstore.out
+++ b/contrib/hstore/expected/hstore.out
@@ -758,36 +758,6 @@ select pg_column_size('a=>g, b=>c'::hstore || ('b'=>'gf'))
(1 row)
-- => arrays
-select ARRAY['a','b','asd'] => ARRAY['g','h','i'];
- ?column?
---------------------------------
- "a"=>"g", "b"=>"h", "asd"=>"i"
-(1 row)
-
-select ARRAY['a','b','asd'] => ARRAY['g','h',NULL];
- ?column?
----------------------------------
- "a"=>"g", "b"=>"h", "asd"=>NULL
-(1 row)
-
-select ARRAY['z','y','x'] => ARRAY['1','2','3'];
- ?column?
-------------------------------
- "x"=>"3", "y"=>"2", "z"=>"1"
-(1 row)
-
-select ARRAY['aaa','bb','c','d'] => ARRAY[null::text,null,null,null];
- ?column?
------------------------------------------------
- "c"=>NULL, "d"=>NULL, "bb"=>NULL, "aaa"=>NULL
-(1 row)
-
-select ARRAY['aaa','bb','c','d'] => null;
- ?column?
------------------------------------------------
- "c"=>NULL, "d"=>NULL, "bb"=>NULL, "aaa"=>NULL
-(1 row)
-
select hstore 'aa=>1, b=>2, c=>3' => ARRAY['g','h','i'];
?column?
----------
@@ -812,29 +782,6 @@ select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'];
"b"=>"2", "c"=>"3", "aa"=>"1"
(1 row)
-select quote_literal('{}'::text[] => '{}'::text[]);
- quote_literal
----------------
- ''
-(1 row)
-
-select quote_literal('{}'::text[] => null);
- quote_literal
----------------
- ''
-(1 row)
-
-select ARRAY['a'] => '{}'::text[]; -- error
-ERROR: arrays must have same bounds
-select '{}'::text[] => ARRAY['a']; -- error
-ERROR: arrays must have same bounds
-select pg_column_size(ARRAY['a','b','asd'] => ARRAY['g','h','i'])
- = pg_column_size('a=>g, b=>h, asd=>i'::hstore);
- ?column?
-----------
- t
-(1 row)
-
select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'])
= pg_column_size('b=>2, c=>3'::hstore);
?column?
@@ -910,6 +857,60 @@ select hstore('[0:2][1:2]={{a,g},{b,h},{asd,i}}'::text[]);
"a"=>"g", "b"=>"h", "asd"=>"i"
(1 row)
+-- pairs of arrays
+select hstore(ARRAY['a','b','asd'], ARRAY['g','h','i']);
+ hstore
+--------------------------------
+ "a"=>"g", "b"=>"h", "asd"=>"i"
+(1 row)
+
+select hstore(ARRAY['a','b','asd'], ARRAY['g','h',NULL]);
+ hstore
+---------------------------------
+ "a"=>"g", "b"=>"h", "asd"=>NULL
+(1 row)
+
+select hstore(ARRAY['z','y','x'], ARRAY['1','2','3']);
+ hstore
+------------------------------
+ "x"=>"3", "y"=>"2", "z"=>"1"
+(1 row)
+
+select hstore(ARRAY['aaa','bb','c','d'], ARRAY[null::text,null,null,null]);
+ hstore
+-----------------------------------------------
+ "c"=>NULL, "d"=>NULL, "bb"=>NULL, "aaa"=>NULL
+(1 row)
+
+select hstore(ARRAY['aaa','bb','c','d'], null);
+ hstore
+-----------------------------------------------
+ "c"=>NULL, "d"=>NULL, "bb"=>NULL, "aaa"=>NULL
+(1 row)
+
+select quote_literal(hstore('{}'::text[], '{}'::text[]));
+ quote_literal
+---------------
+ ''
+(1 row)
+
+select quote_literal(hstore('{}'::text[], null));
+ quote_literal
+---------------
+ ''
+(1 row)
+
+select hstore(ARRAY['a'], '{}'::text[]); -- error
+ERROR: arrays must have same bounds
+select hstore('{}'::text[], ARRAY['a']); -- error
+ERROR: arrays must have same bounds
+select pg_column_size(hstore(ARRAY['a','b','asd'], ARRAY['g','h','i']))
+ = pg_column_size('a=>g, b=>h, asd=>i'::hstore);
+ ?column?
+----------
+ t
+(1 row)
+
-- records
select hstore(v) from (values (1, 'foo', 1.2, 3::float8)) v(a,b,c,d);
hstore
diff --git a/contrib/hstore/hstore.sql.in b/contrib/hstore/hstore.sql.in
index 972557a..aa33829 100644
--- a/contrib/hstore/hstore.sql.in
+++ b/contrib/hstore/hstore.sql.in
@@ -238,12 +238,6 @@ RETURNS hstore
AS 'MODULE_PATHNAME', 'hstore_from_arrays'
LANGUAGE C IMMUTABLE; -- not STRICT; allows (keys,null)
-CREATE OPERATOR => (
- LEFTARG = text[],
- RIGHTARG = text[],
- PROCEDURE = hstore
-);
-
CREATE FUNCTION hstore(text[])
RETURNS hstore
AS 'MODULE_PATHNAME', 'hstore_from_array'
diff --git a/contrib/hstore/sql/hstore.sql b/contrib/hstore/sql/hstore.sql
index a88ff1d..190d7a2 100644
--- a/contrib/hstore/sql/hstore.sql
+++ b/contrib/hstore/sql/hstore.sql
@@ -172,21 +172,10 @@ select pg_column_size('a=>g, b=>c'::hstore || ('b'=>'gf'))
= pg_column_size('a=>g, b=>gf'::hstore);
-- => arrays
-select ARRAY['a','b','asd'] => ARRAY['g','h','i'];
-select ARRAY['a','b','asd'] => ARRAY['g','h',NULL];
-select ARRAY['z','y','x'] => ARRAY['1','2','3'];
-select ARRAY['aaa','bb','c','d'] => ARRAY[null::text,null,null,null];
-select ARRAY['aaa','bb','c','d'] => null;
select hstore 'aa=>1, b=>2, c=>3' => ARRAY['g','h','i'];
select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'];
select hstore 'aa=>1, b=>2, c=>3' => ARRAY['aa','b'];
select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'];
-select quote_literal('{}'::text[] => '{}'::text[]);
-select quote_literal('{}'::text[] => null);
-select ARRAY['a'] => '{}'::text[]; -- error
-select '{}'::text[] => ARRAY['a']; -- error
-select pg_column_size(ARRAY['a','b','asd'] => ARRAY['g','h','i'])
- = pg_column_size('a=>g, b=>h, asd=>i'::hstore);
select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'])
= pg_column_size('b=>2, c=>3'::hstore);
select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'])
@@ -208,6 +197,19 @@ select hstore(ARRAY[[['a','g'],['b','h'],['asd','i']]]);
select hstore('[0:5]={a,g,b,h,asd,i}'::text[]);
select hstore('[0:2][1:2]={{a,g},{b,h},{asd,i}}'::text[]);
+-- pairs of arrays
+select hstore(ARRAY['a','b','asd'], ARRAY['g','h','i']);
+select hstore(ARRAY['a','b','asd'], ARRAY['g','h',NULL]);
+select hstore(ARRAY['z','y','x'], ARRAY['1','2','3']);
+select hstore(ARRAY['aaa','bb','c','d'], ARRAY[null::text,null,null,null]);
+select hstore(ARRAY['aaa','bb','c','d'], null);
+select quote_literal(hstore('{}'::text[], '{}'::text[]));
+select quote_literal(hstore('{}'::text[], null));
+select hstore(ARRAY['a'], '{}'::text[]); -- error
+select hstore('{}'::text[], ARRAY['a']); -- error
+select pg_column_size(hstore(ARRAY['a','b','asd'], ARRAY['g','h','i']))
+ = pg_column_size('a=>g, b=>h, asd=>i'::hstore);
+
-- records
select hstore(v) from (values (1, 'foo', 1.2, 3::float8)) v(a,b,c,d);
create domain hstestdom1 as integer not null default 0;
diff --git a/doc/src/sgml/hstore.sgml b/doc/src/sgml/hstore.sgml
index 65be452..d65a487 100644
--- a/doc/src/sgml/hstore.sgml
+++ b/doc/src/sgml/hstore.sgml
@@ -121,13 +121,6 @@
</row>
<row>
- <entry><type>text[]</> <literal>=></> <type>text[]</></entry>
- <entry>construct an <type>hstore</> from separate key and value arrays</entry>
- <entry><literal>ARRAY['a','b'] => ARRAY['1','2']</literal></entry>
- <entry><literal>"a"=>"1","b"=>"2"</literal></entry>
- </row>
-
- <row>
<entry><type>hstore</> <literal>=></> <type>text[]</></entry>
<entry>extract a subset of an <type>hstore</></entry>
<entry><literal>'a=>1,b=>2,c=>3'::hstore => ARRAY['b','c','x']</literal></entry>
@@ -265,6 +258,14 @@
</row>
<row>
+ <entry><function>hstore(text[], text[])</function></entry>
+ <entry><type>hstore</type></entry>
+ <entry>construct an <type>hstore</> from separate key and value arrays</entry>
+ <entry><literal>hstore(ARRAY['a','b'], ARRAY['1','2'])</literal></entry>
+ <entry><literal>"a"=>"1","b"=>"2"</literal></entry>
+ </row>
+
+ <row>
<entry><function>akeys(hstore)</function></entry>
<entry><type>text[]</type></entry>
<entry>get <type>hstore</>'s keys as an array</entry>
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> But actually, there's another issue here: hstore defines not one
Tom> but three => operators:
Tom> text => text yields hstore (with 1 element)
Tom> text[] => text[] yields hstore (with N elements)
Tom> hstore => text[] yields hstore (subset)
Tom> It's reasonable to say that the first two are bad design, but
Tom> I'm a bit less willing to say that the last one is. What shall
Tom> we do with that?
I added the second two primarily by analogy with the first; following
the existing pattern seemed to be the way to go at the time.
If the first (text => text) operator hadn't already been present when I
started looking at it, I'd probably have stuck to hstore() for all
construction methods rather than defining an operator. Creating operators
that take only existing builtin types is obviously a namespace problem in
that multiple independent modules might get into trouble by choosing the
same operators. Perhaps this should be formalized as some sort of style
guideline for module authors?
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 -> text[]) returns the list of values, whereas
(hstore => text[]) returns both the keys and values.
--
Andrew (irc:RhodiumToad)
On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
<andrew@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
analogy that (hstore -> text[]) returns the list of values, whereas
(hstore => text[]) returns both the keys and values.
So, I kind of like Florian Pflug's suggestion upthread of replacing
hstore => text by hstore & text[]. I think that's about as mnemonic
as we're likely to get, and it gels nicely with the hstore ?& text[]
operator, which tests whether all of the named keys are present in the
hstore.
Does anyone want to bikeshed further before I go do that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:
On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
<andrew@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
analogy that (hstore -> text[]) returns the list of values, whereas
(hstore => text[]) returns both the keys and values.So, I kind of like Florian Pflug's suggestion upthread of replacing
hstore => text by hstore & text[]. I think that's about as mnemonic
as we're likely to get, and it gels nicely with the hstore ?& text[]
operator, which tests whether all of the named keys are present in the
hstore.Does anyone want to bikeshed further before I go do that?
Yeah. It actually doesn't make much sense to me. ?& is all about the keys and their presence, not the values. -> is a much better parallel, it being that it returns the keys in the rhs array. So I think something closer to it would be better. Some suggestions:
~>
<-
#>
+>
Ooh, I like +>, as being: give me more than -> does.
Best,
David
On Tue, Jun 15, 2010 at 9:04 PM, David E. Wheeler <david@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
<andrew@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
analogy that (hstore -> text[]) returns the list of values, whereas
(hstore => text[]) returns both the keys and values.So, I kind of like Florian Pflug's suggestion upthread of replacing
hstore => text by hstore & text[]. I think that's about as mnemonic
as we're likely to get, and it gels nicely with the hstore ?& text[]
operator, which tests whether all of the named keys are present in the
hstore.Does anyone want to bikeshed further before I go do that?
Yeah. It actually doesn't make much sense to me. ?& is all about the keys and their presence, not the values. -> is a much better parallel, it being that it returns the keys in the rhs array. So I think something closer to it would be better.
Well, the idea is it's like logical-and - give me only those keys that
appear on both sides...
Some suggestions:
~>
<-
#>
+>Ooh, I like +>, as being: give me more than -> does.
If there is a critical mass of votes for one of these options, I'm
fine with whatever.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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 whatever.
Put me down for +>.
Best,
David
On Tue, Jun 15, 2010 at 10:55 PM, David E. Wheeler <david@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 there is a critical mass of votes for one of these options, I'm
fine with whatever.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Attachments:
hstore_arrow_text_to_logical_and.patchapplication/octet-stream; name=hstore_arrow_text_to_logical_and.patchDownload
diff --git a/contrib/hstore/hstore.sql.in b/contrib/hstore/hstore.sql.in
index aa33829..4d01a31 100644
--- a/contrib/hstore/hstore.sql.in
+++ b/contrib/hstore/hstore.sql.in
@@ -66,7 +66,7 @@ RETURNS hstore
AS 'MODULE_PATHNAME','hstore_slice_to_hstore'
LANGUAGE C STRICT IMMUTABLE;
-CREATE OPERATOR => (
+CREATE OPERATOR & (
LEFTARG = hstore,
RIGHTARG = text[],
PROCEDURE = slice_hstore
diff --git a/contrib/hstore/sql/hstore.sql b/contrib/hstore/sql/hstore.sql
index 190d7a2..00b31a5 100644
--- a/contrib/hstore/sql/hstore.sql
+++ b/contrib/hstore/sql/hstore.sql
@@ -171,14 +171,14 @@ select pg_column_size(('b'=>'gf'))
select pg_column_size('a=>g, b=>c'::hstore || ('b'=>'gf'))
= pg_column_size('a=>g, b=>gf'::hstore);
--- => arrays
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['g','h','i'];
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'];
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['aa','b'];
-select hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'];
-select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b'])
+-- &
+select hstore 'aa=>1, b=>2, c=>3' & ARRAY['g','h','i'];
+select hstore 'aa=>1, b=>2, c=>3' & ARRAY['c','b'];
+select hstore 'aa=>1, b=>2, c=>3' & ARRAY['aa','b'];
+select hstore 'aa=>1, b=>2, c=>3' & ARRAY['c','b','aa'];
+select pg_column_size(hstore 'aa=>1, b=>2, c=>3' & ARRAY['c','b'])
= pg_column_size('b=>2, c=>3'::hstore);
-select pg_column_size(hstore 'aa=>1, b=>2, c=>3' => ARRAY['c','b','aa'])
+select pg_column_size(hstore 'aa=>1, b=>2, c=>3' & ARRAY['c','b','aa'])
= pg_column_size('aa=>1, b=>2, c=>3'::hstore);
-- array input
diff --git a/contrib/hstore/uninstall_hstore.sql b/contrib/hstore/uninstall_hstore.sql
index 27463b9..f524c3d 100644
--- a/contrib/hstore/uninstall_hstore.sql
+++ b/contrib/hstore/uninstall_hstore.sql
@@ -22,8 +22,7 @@ DROP OPERATOR <@ ( hstore, hstore );
DROP OPERATOR @ ( hstore, hstore );
DROP OPERATOR ~ ( hstore, hstore );
DROP OPERATOR => ( text, text );
-DROP OPERATOR => ( text[], text[] );
-DROP OPERATOR => ( hstore, text[] );
+DROP OPERATOR & ( hstore, text[] );
DROP OPERATOR #= ( anyelement, hstore );
DROP OPERATOR %% ( NONE, hstore );
DROP OPERATOR %# ( NONE, hstore );
diff --git a/doc/src/sgml/hstore.sgml b/doc/src/sgml/hstore.sgml
index d65a487..cac4d42 100644
--- a/doc/src/sgml/hstore.sgml
+++ b/doc/src/sgml/hstore.sgml
@@ -121,9 +121,9 @@
</row>
<row>
- <entry><type>hstore</> <literal>=></> <type>text[]</></entry>
+ <entry><type>hstore</> <literal>&</> <type>text[]</></entry>
<entry>extract a subset of an <type>hstore</></entry>
- <entry><literal>'a=>1,b=>2,c=>3'::hstore => ARRAY['b','c','x']</literal></entry>
+ <entry><literal>'a=>1,b=>2,c=>3'::hstore & ARRAY['b','c','x']</literal></entry>
<entry><literal>"b"=>"2", "c"=>"3"</literal></entry>
</row>
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 is that & looks like boolean or bitwise AND, so the return of an hstore might be unexpected. +> looks more like an arrow (sort of).
But it doesn't much matter, as long as it works.
Best,
David
Robert Haas <robertmhaas@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 compatibility?
I thought the idea was to deprecate => for a release or so, not kill it
on the spot.
regards, tom lane
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
"David E. Wheeler" <david@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 this as being the other operator. Nevermind ...
(FWIW, I share your dislike of & for this operator. I just haven't
got a better idea.)
regards, tom lane
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:
text[] key_slice := my_hstore -> ARRAY['foo', 'bar'];
bool has_keys := my_hstore ?& ARRAY['foo', 'bar'];
text[] keyvals := %% my_hstore;
text[] keyvals := %# my_hstore;
Frankly, %% and %# are closest, in a sense. But instead of an array, we want to get back an hstore. -> and ?& are correlates in that their RHSs are arrays.
Possible operators to get a slice of the hstore:
hstore slice := my_hstore +> ARRAY['foo', 'bar'];
hstore slice := my_hstore #> ARRAY['foo', 'bar'];
hstore slice := my_hstore &> ARRAY['foo', 'bar'];
hstore slice := my_hstore !> ARRAY['foo', 'bar'];
hstore slice := my_hstore *> ARRAY['foo', 'bar'];
hstore slice := my_hstore %> ARRAY['foo', 'bar'];
hstore slice := my_hstore @ ARRAY['foo', 'bar'];
hstore slice := my_hstore % ARRAY['foo', 'bar'];
hstore slice := my_hstore # ARRAY['foo', 'bar'];
hstore slice := my_hstore & ARRAY['foo', 'bar'];
hstore slice := my_hstore @# ARRAY['foo', 'bar'];
Maybe %> is good, in that it combines %% and ->, in a sense. Or #>, which kind of goes along with #=, which also returns an hstore.
Anyway, the more I look at it the less I care, as long as *something* works.
Best,
David
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.)There aren't any very good choices.
Since there seems to be no consensus on this, maybe thats a sign that there shouldn't be an operator for this at all. I suggested & due due the similarities to ?&, but I can see why people object to that - mainly because it looks like an predicate, not like an operation on hstores.
How about turning it into a function
hstore hstore(hstore, text[])
instead?
Could also be hstore_restrict if people think naming it just hstore is ambiguous.
best regards,
Florian Pflug
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 || instead?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh@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 doing is appending an array of text to an
Hstore, shouldn't we use || instead?
It isn't. || already does what you're saying.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On 6/17/10 1:40 PM, Robert Haas wrote:
On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh@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 doing is appending an array of text to an
Hstore, shouldn't we use || instead?It isn't. || already does what you're saying.
So what *does* it do?
OK, so after a brief poll on IRC, one reason you're not getting coherent
feedback on this is that few people understand the operators which
hstore 9.0 already uses and which are new for 9.0, let alone what new
operators are proposed for each thing. I know I've completely lost
track, particularly since doc patches haven't kept up with the code
changes. I've reread most of this thread and it doesn't help me.
On the other hand, maybe less feedback is less bikeshedding. You decide.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
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 => ARRAY['b','c','x']
Result is:
'"b"=>"2", "c"=>"3"'::hstore
Best,
David
On Thu, Jun 17, 2010 at 4:50 PM, Josh Berkus <josh@agliodbs.com> wrote:
On 6/17/10 1:40 PM, Robert Haas wrote:
On Thu, Jun 17, 2010 at 4:39 PM, Josh Berkus <josh@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 doing is appending an array of text to an
Hstore, shouldn't we use || instead?It isn't. || already does what you're saying.
So what *does* it do?
OK, so after a brief poll on IRC, one reason you're not getting coherent
feedback on this is that few people understand the operators which
hstore 9.0 already uses and which are new for 9.0, let alone what new
operators are proposed for each thing. I know I've completely lost
track, particularly since doc patches haven't kept up with the code
changes. I've reread most of this thread and it doesn't help me.On the other hand, maybe less feedback is less bikeshedding. You decide.
Well, they are documented, so you can read up on them...
http://developer.postgresql.org/pgdocs/postgres/hstore.html
This isn't a critical issue in desperate need of community input; we
just need to resolve it one way or the other so we can move on to the
next thing. I'm still inclined to go ahead and apply the patch I
attached upthread, because that is less work for me than doing
anything else...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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/pgdocs/postgres/hstore.html):
OK, hammered this out on IRC with several Hstore users, and I think the
best answer here is consistency. Both with the other hstore operators
and with other set types, such as intarray and ltree.
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 %.
I vote for % .
Stuff we discussed and discarded includes:
& for two reasons: (a) it looks like a predicate and (b) it's used as
"intersect" for intarray and ltree, and we might want to implement
intersect for hstore someday.
# because it's used as "index" for intarray, and thus should more
properly be a synonym for -> in hstore
+> because it looks like it ought to be some kind of special incrementor.
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' )
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
Josh Berkus <josh@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 operators. Extrapolating from those to an
infix operator seems a bit thin. Nonetheless, something using % seems
better than something using &, for the other reasons you mention.
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.
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.
regards, tom lane
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.
%!> then. :-)
David
Tom Lane wrote:
Josh Berkus <josh@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 operators. Extrapolating from those to an
infix operator seems a bit thin. Nonetheless, something using % seems
better than something using &, for the other reasons you mention.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.
I think this bikeshed is going to be more paint than shed. However, I
just wondered about | as the operator. Think of the right hand operand
as a filter on the hstore, and a pipe seems to work.
Lots of operators aren't commutative. Arithmetic % for example ;-)
But honestly, I can live with just about anything.
cheers
andrew
On Thu, Jun 17, 2010 at 11:04 PM, Andrew Dunstan <andrew@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 aren't commutative. Arithmetic % for example ;-)
I've committed this as % -- if anyone cares about it enough to keep
arguing, we can change it again.
I think this bikeshed is going to be more paint than shed.
You said it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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 ... )
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
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
On Fri, Jun 18, 2010 at 6:26 PM, David E. Wheeler <david@kineticode.com> wrote:
+1 from me, too.
1 isn't a valid character in a postgres operator
:P
--
greg
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, does the spec say anything about array operators?
Best,
David
On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler <david@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 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
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 arrays.
And looking again at the options, I'm *okay* with %, but not keen on %> anymore (I could see a future where %> and <% it as complement @> and <@ by confirming the presence of keys in an hstore:
bool = hstore %> text[];
So, frankly, I'm coming back to what Florian has suggested here. What about calling it slice?
hstore = slice(hstore, text[]);
It'd be nice to have one for arrays, too:
anyarray[] = slice(anyarray[], int[]);
An operator could always be added later if a good one appeared.
Okay, no more bikeshedding for me on this issue. I'm covered in paint.
Best,
David
On Mon, Jun 21, 2010 at 1:37 PM, David E. Wheeler <david@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 empty. It seems to define a bunch of predicates for multisets, but not much for arrays.
And looking again at the options, I'm *okay* with %, but not keen on %> anymore (I could see a future where %> and <% it as complement @> and <@ by confirming the presence of keys in an hstore:
bool = hstore %> text[];
So, frankly, I'm coming back to what Florian has suggested here. What about calling it slice?
hstore = slice(hstore, text[]);
It'd be nice to have one for arrays, too:
anyarray[] = slice(anyarray[], int[]);
An operator could always be added later if a good one appeared.
Okay, no more bikeshedding for me on this issue. I'm covered in paint.
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(), but I can't talk about it right now because I have to go
finish laundering the paint out of my entire wardrobe. Having already
written three patches to rename this operator (to three different
names), I'm in no hurry to write a fourth unless the degree of
consensus is sufficient to convince me I shan't need to write a fifth
one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
"David E. Wheeler" <david@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".
regards, tom lane
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 probably prefer hstore_slice() or just
slice(), but I can't talk about it right now because I have to go
finish laundering the paint out of my entire wardrobe. Having already
written three patches to rename this operator (to three different
names), I'm in no hurry to write a fourth unless the degree of
consensus is sufficient to convince me I shan't need to write a fifth
one.
That seems wise. :-)
Best,
David
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(), but I can't talk about it right now because I have to go
finish laundering the paint out of my entire wardrobe. Having already
written three patches to rename this operator (to three different
names), I'm in no hurry to write a fourth unless the degree of
consensus is sufficient to convince me I shan't need to write a fifth
one.
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.
In some ways, it makes more sense to talk about additional operators in
the context of also adding them to intarray, and I don't want to go
there yet.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
Josh Berkus <josh@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 consensus is to avoid picking an operator name at all.
"slice()" is OK by me.
regards, tom lane
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 think the consensus is to avoid picking an operator name at all.
"slice()" is OK by me.
Will this be done for Beta 3?
Best,
David
On Fri, Jul 2, 2010 at 12:36 PM, David E. Wheeler <david@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 as the function slice(), and defer having
an operator until later.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. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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 `slice_array()` function, which is used by the `->` operator. I think I might like to see it renamed `avals(hstore, text[])` if it ever gets documented, as it nicely complements the existing `avals(hstore)` function.
Best,
David
Attachments:
hstore_slice.patchapplication/octet-stream; name=hstore_slice.patchDownload
diff --git a/contrib/hstore/expected/hstore.out b/contrib/hstore/expected/hstore.out
index 9f15a9b..e78264d 100644
*** a/contrib/hstore/expected/hstore.out
--- b/contrib/hstore/expected/hstore.out
***************
*** 4,10 ****
--
SET client_min_messages = warning;
\set ECHO none
! psql:hstore.sql:234: WARNING: => is deprecated as an operator name
DETAIL: This name may be disallowed altogether in future versions of PostgreSQL.
RESET client_min_messages;
set escape_string_warning=off;
--- 4,10 ----
--
SET client_min_messages = warning;
\set ECHO none
! psql:hstore.sql:228: WARNING: => is deprecated as an operator name
DETAIL: This name may be disallowed altogether in future versions of PostgreSQL.
RESET client_min_messages;
set escape_string_warning=off;
*************** select pg_column_size('a=>g, b=>c'::hsto
*** 759,797 ****
t
(1 row)
! -- %
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['g','h','i'];
! ?column?
! ----------
(1 row)
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b'];
! ?column?
--------------------
"b"=>"2", "c"=>"3"
(1 row)
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['aa','b'];
! ?column?
---------------------
"b"=>"2", "aa"=>"1"
(1 row)
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b','aa'];
! ?column?
-------------------------------
"b"=>"2", "c"=>"3", "aa"=>"1"
(1 row)
! select pg_column_size(hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b'])
= pg_column_size('b=>2, c=>3'::hstore);
?column?
----------
t
(1 row)
! select pg_column_size(hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b','aa'])
= pg_column_size('aa=>1, b=>2, c=>3'::hstore);
?column?
----------
--- 759,797 ----
t
(1 row)
! -- slice()
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['g','h','i']);
! slice
! -------
(1 row)
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']);
! slice
--------------------
"b"=>"2", "c"=>"3"
(1 row)
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['aa','b']);
! slice
---------------------
"b"=>"2", "aa"=>"1"
(1 row)
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']);
! slice
-------------------------------
"b"=>"2", "c"=>"3", "aa"=>"1"
(1 row)
! select pg_column_size(slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']))
= pg_column_size('b=>2, c=>3'::hstore);
?column?
----------
t
(1 row)
! select pg_column_size(slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']))
= pg_column_size('aa=>1, b=>2, c=>3'::hstore);
?column?
----------
diff --git a/contrib/hstore/hstore.sql.in b/contrib/hstore/hstore.sql.in
index f77e562..0862cf1 100644
*** a/contrib/hstore/hstore.sql.in
--- b/contrib/hstore/hstore.sql.in
*************** CREATE OPERATOR -> (
*** 61,77 ****
PROCEDURE = slice_array
);
! CREATE OR REPLACE FUNCTION slice_hstore(hstore,text[])
RETURNS hstore
AS 'MODULE_PATHNAME','hstore_slice_to_hstore'
LANGUAGE C STRICT IMMUTABLE;
- CREATE OPERATOR % (
- LEFTARG = hstore,
- RIGHTARG = text[],
- PROCEDURE = slice_hstore
- );
-
CREATE OR REPLACE FUNCTION isexists(hstore,text)
RETURNS bool
AS 'MODULE_PATHNAME','hstore_exists'
--- 61,71 ----
PROCEDURE = slice_array
);
! CREATE OR REPLACE FUNCTION slice(hstore,text[])
RETURNS hstore
AS 'MODULE_PATHNAME','hstore_slice_to_hstore'
LANGUAGE C STRICT IMMUTABLE;
CREATE OR REPLACE FUNCTION isexists(hstore,text)
RETURNS bool
AS 'MODULE_PATHNAME','hstore_exists'
diff --git a/contrib/hstore/sql/hstore.sql b/contrib/hstore/sql/hstore.sql
index a066f11..8fefcbb 100644
*** a/contrib/hstore/sql/hstore.sql
--- b/contrib/hstore/sql/hstore.sql
*************** select pg_column_size(('b'=>'gf'))
*** 171,184 ****
select pg_column_size('a=>g, b=>c'::hstore || ('b'=>'gf'))
= pg_column_size('a=>g, b=>gf'::hstore);
! -- %
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['g','h','i'];
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b'];
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['aa','b'];
! select hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b','aa'];
! select pg_column_size(hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b'])
= pg_column_size('b=>2, c=>3'::hstore);
! select pg_column_size(hstore 'aa=>1, b=>2, c=>3' % ARRAY['c','b','aa'])
= pg_column_size('aa=>1, b=>2, c=>3'::hstore);
-- array input
--- 171,184 ----
select pg_column_size('a=>g, b=>c'::hstore || ('b'=>'gf'))
= pg_column_size('a=>g, b=>gf'::hstore);
! -- slice()
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['g','h','i']);
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']);
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['aa','b']);
! select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']);
! select pg_column_size(slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']))
= pg_column_size('b=>2, c=>3'::hstore);
! select pg_column_size(slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']))
= pg_column_size('aa=>1, b=>2, c=>3'::hstore);
-- array input
diff --git a/contrib/hstore/uninstall_hstore.sql b/contrib/hstore/uninstall_hstore.sql
index 651846d..71dffc2 100644
*** a/contrib/hstore/uninstall_hstore.sql
--- b/contrib/hstore/uninstall_hstore.sql
*************** DROP OPERATOR <@ ( hstore, hstore );
*** 22,28 ****
DROP OPERATOR @ ( hstore, hstore );
DROP OPERATOR ~ ( hstore, hstore );
DROP OPERATOR => ( text, text );
- DROP OPERATOR % ( hstore, text[] );
DROP OPERATOR #= ( anyelement, hstore );
DROP OPERATOR %% ( NONE, hstore );
DROP OPERATOR %# ( NONE, hstore );
--- 22,27 ----
*************** DROP FUNCTION hstore_le(hstore,hstore);
*** 44,50 ****
DROP FUNCTION hstore_cmp(hstore,hstore);
DROP FUNCTION hstore_hash(hstore);
DROP FUNCTION slice_array(hstore,text[]);
! DROP FUNCTION slice_hstore(hstore,text[]);
DROP FUNCTION fetchval(hstore,text);
DROP FUNCTION isexists(hstore,text);
DROP FUNCTION exist(hstore,text);
--- 43,49 ----
DROP FUNCTION hstore_cmp(hstore,hstore);
DROP FUNCTION hstore_hash(hstore);
DROP FUNCTION slice_array(hstore,text[]);
! DROP FUNCTION slice(hstore,text[]);
DROP FUNCTION fetchval(hstore,text);
DROP FUNCTION isexists(hstore,text);
DROP FUNCTION exist(hstore,text);
diff --git a/doc/src/sgml/hstore.sgml b/doc/src/sgml/hstore.sgml
index a774d51..e02d478 100644
*** a/doc/src/sgml/hstore.sgml
--- b/doc/src/sgml/hstore.sgml
***************
*** 83,89 ****
</sect2>
<sect2>
! <title><type>hstore</> Operators and Functions</title>
<table id="hstore-op-table">
<title><type>hstore</> Operators</title>
--- 83,89 ----
</sect2>
<sect2>
! <title><type>hstore</> Operators</title>
<table id="hstore-op-table">
<title><type>hstore</> Operators</title>
***************
*** 121,133 ****
</row>
<row>
- <entry><type>hstore</> <literal>%</> <type>text[]</></entry>
- <entry>extract a subset of an <type>hstore</></entry>
- <entry><literal>'a=>1,b=>2,c=>3'::hstore % ARRAY['b','c','x']</literal></entry>
- <entry><literal>"b"=>"2", "c"=>"3"</literal></entry>
- </row>
-
- <row>
<entry><type>hstore</> <literal>||</> <type>hstore</></entry>
<entry>concatenate <type>hstore</>s</entry>
<entry><literal>'a=>b, c=>d'::hstore || 'c=>x, d=>q'::hstore</literal></entry>
--- 121,126 ----
*************** b
*** 339,344 ****
--- 332,345 ----
</row>
<row>
+ <entry><function>slice(hstore, text[])</function></entry>
+ <entry><type>hstore</type></entry>
+ <entry>extract a subset of an <type>hstore</></entry>
+ <entry><literal>slice('a=>1,b=>2,c=>3'::hstore, ARRAY['b','c','x'])</literal></entry>
+ <entry><literal>"b"=>"2", "c"=>"3"</literal></entry>
+ </row>
+
+ <row>
<entry><function>each(hstore)</function></entry>
<entry><type>setof(key text, value text)</type></entry>
<entry>get <type>hstore</>'s keys and values as a set</entry>
On Fri, Jul 2, 2010 at 2:39 PM, David E. Wheeler <david@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. :-)
Attached.
Only thing that gave me pause is the presence of the undocumented `slice_array()` function, which is used by the `->` operator. I think I might like to see it renamed `avals(hstore, text[])` if it ever gets documented, as it nicely complements the existing `avals(hstore)` function.
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).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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://developer.postgresql.org/docs/postgres/hstore.html.
Best,
David
On Fri, Jul 2, 2010 at 4:43 PM, David E. Wheeler <david@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 removed that because that table has only operators, no functions. See http://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 functions", and those two
tables together make up a section called "F.13.2 hstore operators and
functions".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
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 functions", and those two
tables together make up a section called "F.13.2 hstore operators and
functions".
Oh. Duh.
David
"David E. Wheeler" <david@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
On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David E. Wheeler" <david@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?
It used to be =>
After much bikeshedding, we renamed it to %
After more bikeshedding, we decided to remove it altogether, hence the
present patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl@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. Obviously time to knock off for the day;
my brain's fried.
regards, tom lane
On Fri, Jul 2, 2010 at 5:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Jul 2, 2010 at 5:00 PM, Tom Lane <tgl@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. Obviously time to knock off for the day;
my brain's fried.
Just as long as you don't ask to have it changed again. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company