proposal: disallow operator "=>" and use it for named parameters
Hello
two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
I am sending a implementation where syntax based on "=>" symbol is second
(but preferred) variant of ":=" syntax .. syntax ":=" will be supported
still.
Here is a patch
comments, notices?
Regards
Pavel
Attachments:
ansi-sql-named-parameters.patchtext/x-patch; charset=US-ASCII; name=ansi-sql-named-parameters.patchDownload
commit 857c079d6b8030c575da129bb142860e8f6f951e
Author: Pavel Stehule <pavel.stehule@gooddata.com>
Date: Sun Jan 18 02:25:48 2015 +0100
initial implementation
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5e7b000..c33190e 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -6785,7 +6785,7 @@ SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
Create interval from years, months, weeks, days, hours, minutes and
seconds fields
</entry>
- <entry><literal>make_interval(days := 10)</literal></entry>
+ <entry><literal>make_interval(days => 10)</literal></entry>
<entry><literal>10 days</literal></entry>
</row>
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 4b81b08..d30db6a 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -2599,7 +2599,7 @@ SELECT concat_lower_or_upper('Hello', 'World');
<literal>:=</literal> to separate it from the argument expression.
For example:
<screen>
-SELECT concat_lower_or_upper(a := 'Hello', b := 'World');
+SELECT concat_lower_or_upper(a => 'Hello', b => 'World');
concat_lower_or_upper
-----------------------
hello world
@@ -2610,13 +2610,24 @@ SELECT concat_lower_or_upper(a := 'Hello', b := 'World');
using named notation is that the arguments may be specified in any
order, for example:
<screen>
-SELECT concat_lower_or_upper(a := 'Hello', b := 'World', uppercase := true);
+SELECT concat_lower_or_upper(a => 'Hello', b => 'World', uppercase => true);
concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
-SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
+SELECT concat_lower_or_upper(a => 'Hello', uppercase => true, b => 'World');
+ concat_lower_or_upper
+-----------------------
+ HELLO WORLD
+(1 row)
+</screen>
+ </para>
+
+ <para>
+ Older syntax based on ":=" symbol is still supported:
+<screen>
+ SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
concat_lower_or_upper
-----------------------
HELLO WORLD
@@ -2638,7 +2649,7 @@ SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
already mentioned, named arguments cannot precede positional arguments.
For example:
<screen>
-SELECT concat_lower_or_upper('Hello', 'World', uppercase := true);
+SELECT concat_lower_or_upper('Hello', 'World', uppercase => true);
concat_lower_or_upper
-----------------------
HELLO WORLD
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index f40504c..264e5ff 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -776,14 +776,14 @@ SELECT mleast(VARIADIC ARRAY[]::numeric[]);
<literal>VARIADIC</>. For example, this will work:
<screen>
-SELECT mleast(VARIADIC arr := ARRAY[10, -1, 5, 4.4]);
+SELECT mleast(VARIADIC arr => ARRAY[10, -1, 5, 4.4]);
</screen>
but not these:
<screen>
-SELECT mleast(arr := 10);
-SELECT mleast(arr := ARRAY[10, -1, 5, 4.4]);
+SELECT mleast(arr => 10);
+SELECT mleast(arr => ARRAY[10, -1, 5, 4.4]);
</screen>
</para>
</sect2>
diff --git a/src/backend/commands/operatorcmds.c b/src/backend/commands/operatorcmds.c
index 2996019..2d26345 100644
--- a/src/backend/commands/operatorcmds.c
+++ b/src/backend/commands/operatorcmds.c
@@ -93,9 +93,8 @@ DefineOperator(List *names, List *parameters)
* as the name of a user-defined operator.
*/
if (strcmp(oprName, "=>") == 0)
- ereport(WARNING,
- (errmsg("=> is deprecated as an operator name"),
- errdetail("This name may be disallowed altogether in future versions of PostgreSQL.")));
+ ereport(ERROR,
+ (errmsg("=> is disallowed as an operator name")));
/* Check we have creation rights in target namespace */
aclresult = pg_namespace_aclcheck(oprNamespace, GetUserId(), ACL_CREATE);
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 36dac29..6a02dcc 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -531,7 +531,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
*/
%token <str> IDENT FCONST SCONST BCONST XCONST Op
%token <ival> ICONST PARAM
-%token TYPECAST DOT_DOT COLON_EQUALS
+%token TYPECAST DOT_DOT COLON_EQUALS EQUALS_GREATER
/*
* If you want to make any keyword changes, update the keyword table in
@@ -12557,6 +12557,15 @@ func_arg_expr: a_expr
na->location = @1;
$$ = (Node *) na;
}
+ | param_name EQUALS_GREATER a_expr
+ {
+ NamedArgExpr *na = makeNode(NamedArgExpr);
+ na->name = $1;
+ na->arg = (Expr *) $3;
+ na->argnumber = -1; /* until determined */
+ na->location = @1;
+ $$ = (Node *) na;
+ }
;
type_list: Typename { $$ = list_make1($1); }
diff --git a/src/backend/parser/scan.l b/src/backend/parser/scan.l
index 21a6f30..743df71 100644
--- a/src/backend/parser/scan.l
+++ b/src/backend/parser/scan.l
@@ -334,6 +334,7 @@ identifier {ident_start}{ident_cont}*
typecast "::"
dot_dot \.\.
colon_equals ":="
+equals_greater "=>"
/*
* "self" is the set of chars that should be returned as single-character
@@ -808,6 +809,11 @@ other .
return COLON_EQUALS;
}
+{equals_greater} {
+ SET_YYLLOC();
+ return EQUALS_GREATER;
+ }
+
{self} {
SET_YYLLOC();
return yytext[0];
diff --git a/src/test/regress/expected/create_operator.out b/src/test/regress/expected/create_operator.out
index 2e6c764..3a216c2 100644
--- a/src/test/regress/expected/create_operator.out
+++ b/src/test/regress/expected/create_operator.out
@@ -29,13 +29,14 @@ CREATE OPERATOR #%# (
-- Test comments
COMMENT ON OPERATOR ###### (int4, NONE) IS 'bad right unary';
ERROR: operator does not exist: integer ######
--- Show deprecated message. => is deprecated now
+-- => is disallowed now
CREATE OPERATOR => (
leftarg = int8, -- right unary
procedure = numeric_fac
);
-WARNING: => is deprecated as an operator name
-DETAIL: This name may be disallowed altogether in future versions of PostgreSQL.
+ERROR: syntax error at or near "=>"
+LINE 1: CREATE OPERATOR => (
+ ^
-- Should fail. CREATE OPERATOR requires USAGE on SCHEMA
BEGIN TRANSACTION;
CREATE ROLE regress_rol_op1;
diff --git a/src/test/regress/expected/polymorphism.out b/src/test/regress/expected/polymorphism.out
index 27b2879..987b3ee 100644
--- a/src/test/regress/expected/polymorphism.out
+++ b/src/test/regress/expected/polymorphism.out
@@ -1356,6 +1356,73 @@ select dfunc('a'::text, 'b', flag := true); -- mixed notation
a
(1 row)
+-- ansi/sql syntax
+select dfunc(a => 1, b => 2);
+ dfunc
+-------
+ 1
+(1 row)
+
+select dfunc(a => 'a'::text, b => 'b');
+ dfunc
+-------
+ a
+(1 row)
+
+select dfunc(a => 'a'::text, b => 'b', flag => false); -- named notation
+ dfunc
+-------
+ b
+(1 row)
+
+select dfunc(b => 'b'::text, a => 'a'); -- named notation with default
+ dfunc
+-------
+ a
+(1 row)
+
+select dfunc(a => 'a'::text, flag => true); -- named notation with default
+ dfunc
+-------
+ a
+(1 row)
+
+select dfunc(a => 'a'::text, flag => false); -- named notation with default
+ dfunc
+-------
+
+(1 row)
+
+select dfunc(b => 'b'::text, a => 'a', flag => true); -- named notation
+ dfunc
+-------
+ a
+(1 row)
+
+select dfunc('a'::text, 'b', false); -- full positional notation
+ dfunc
+-------
+ b
+(1 row)
+
+select dfunc('a'::text, 'b', flag => false); -- mixed notation
+ dfunc
+-------
+ b
+(1 row)
+
+select dfunc('a'::text, 'b', true); -- full positional notation
+ dfunc
+-------
+ a
+(1 row)
+
+select dfunc('a'::text, 'b', flag => true); -- mixed notation
+ dfunc
+-------
+ a
+(1 row)
+
-- check reverse-listing of named-arg calls
CREATE VIEW dfview AS
SELECT q1, q2,
diff --git a/src/test/regress/sql/create_operator.sql b/src/test/regress/sql/create_operator.sql
index f7a372a..0e5d635 100644
--- a/src/test/regress/sql/create_operator.sql
+++ b/src/test/regress/sql/create_operator.sql
@@ -35,7 +35,7 @@ CREATE OPERATOR #%# (
-- Test comments
COMMENT ON OPERATOR ###### (int4, NONE) IS 'bad right unary';
--- Show deprecated message. => is deprecated now
+-- => is disallowed now
CREATE OPERATOR => (
leftarg = int8, -- right unary
procedure = numeric_fac
diff --git a/src/test/regress/sql/polymorphism.sql b/src/test/regress/sql/polymorphism.sql
index 3d8dd1e..72f6cb5 100644
--- a/src/test/regress/sql/polymorphism.sql
+++ b/src/test/regress/sql/polymorphism.sql
@@ -748,6 +748,22 @@ select dfunc('a'::text, 'b', flag := false); -- mixed notation
select dfunc('a'::text, 'b', true); -- full positional notation
select dfunc('a'::text, 'b', flag := true); -- mixed notation
+-- ansi/sql syntax
+select dfunc(a => 1, b => 2);
+select dfunc(a => 'a'::text, b => 'b');
+select dfunc(a => 'a'::text, b => 'b', flag => false); -- named notation
+
+select dfunc(b => 'b'::text, a => 'a'); -- named notation with default
+select dfunc(a => 'a'::text, flag => true); -- named notation with default
+select dfunc(a => 'a'::text, flag => false); -- named notation with default
+select dfunc(b => 'b'::text, a => 'a', flag => true); -- named notation
+
+select dfunc('a'::text, 'b', false); -- full positional notation
+select dfunc('a'::text, 'b', flag => false); -- mixed notation
+select dfunc('a'::text, 'b', true); -- full positional notation
+select dfunc('a'::text, 'b', flag => true); -- mixed notation
+
+
-- check reverse-listing of named-arg calls
CREATE VIEW dfview AS
SELECT q1, q2,
On Sat, Jan 17, 2015 at 8:27 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
I'm cool with that. It's possible that there are installations out
there that still have => operators installed, but every
still-supported release warns you not to do that, and the hstore
change exists in three released versions. Anyway, no amount of
waiting will eliminate the hazard completely.
I am sending a implementation where syntax based on "=>" symbol is second
(but preferred) variant of ":=" syntax .. syntax ":=" will be supported
still.Here is a patch
I think you should just remove the WARNING, not change it to an error.
If somebody wants to quote the operator name to be able to continue
using it, I think that's OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-19 4:54 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Sat, Jan 17, 2015 at 8:27 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
I'm cool with that. It's possible that there are installations out
there that still have => operators installed, but every
still-supported release warns you not to do that, and the hstore
change exists in three released versions. Anyway, no amount of
waiting will eliminate the hazard completely.I am sending a implementation where syntax based on "=>" symbol is second
(but preferred) variant of ":=" syntax .. syntax ":=" will be supported
still.Here is a patch
I think you should just remove the WARNING, not change it to an error.
If somebody wants to quote the operator name to be able to continue
using it, I think that's OK.
I have no problem with it. Just I'll try if there are no some unexpected
problem and I'll send a updated patch
Regards
Pavel
Show quoted text
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
2015-01-19 4:54 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Sat, Jan 17, 2015 at 8:27 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
I'm cool with that. It's possible that there are installations out
there that still have => operators installed, but every
still-supported release warns you not to do that, and the hstore
change exists in three released versions. Anyway, no amount of
waiting will eliminate the hazard completely.I am sending a implementation where syntax based on "=>" symbol is second
(but preferred) variant of ":=" syntax .. syntax ":=" will be supported
still.Here is a patch
I think you should just remove the WARNING, not change it to an error.
If somebody wants to quote the operator name to be able to continue
using it, I think that's OK.
It looks so quoting doesn't help here
+ CREATE OPERATOR "=>" (
+ leftarg = int8,<--><------>-- right unary
+ procedure = numeric_fac
+ );
+ ERROR: syntax error at or near "("
+ LINE 1: CREATE OPERATOR "=>" (
+ ^Regards
Pavel
Show quoted text
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
I think you should just remove the WARNING, not change it to an error.
If somebody wants to quote the operator name to be able to continue
using it, I think that's OK.It looks so quoting doesn't help here
+ CREATE OPERATOR "=>" ( + leftarg = int8,<--><------>-- right unary + procedure = numeric_fac + ); + ERROR: syntax error at or near "(" + LINE 1: CREATE OPERATOR "=>" ( + ^
Well then the error check is just dead code. Either way, you don't need it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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 wrote:
It looks so quoting doesn't help here
+ CREATE OPERATOR "=>" ( + leftarg = int8,<--><------>-- right unary + procedure = numeric_fac + ); + ERROR: syntax error at or near "(" + LINE 1: CREATE OPERATOR "=>" ( + ^
Does it work to use OPERATOR(=>) syntax? I don't think identifier
quoting works for operators.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-19 14:30 GMT+01:00 Alvaro Herrera <alvherre@2ndquadrant.com>:
Pavel Stehule wrote:
It looks so quoting doesn't help here
+ CREATE OPERATOR "=>" ( + leftarg = int8,<--><------>-- right unary + procedure = numeric_fac + ); + ERROR: syntax error at or near "(" + LINE 1: CREATE OPERATOR "=>" ( + ^Does it work to use OPERATOR(=>) syntax? I don't think identifier
quoting works for operators.
it doesn't work too
Show quoted text
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2015-01-19 14:27 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:I think you should just remove the WARNING, not change it to an error.
If somebody wants to quote the operator name to be able to continue
using it, I think that's OK.It looks so quoting doesn't help here
+ CREATE OPERATOR "=>" ( + leftarg = int8,<--><------>-- right unary + procedure = numeric_fac + ); + ERROR: syntax error at or near "(" + LINE 1: CREATE OPERATOR "=>" ( + ^Well then the error check is just dead code. Either way, you don't need
it.
yes, I removed it
Regards
Pavel
Show quoted text
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
ansi-sql-named-parameters-02.patchtext/x-patch; charset=US-ASCII; name=ansi-sql-named-parameters-02.patchDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index 5e7b000..c33190e
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*************** SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1
*** 6785,6791 ****
Create interval from years, months, weeks, days, hours, minutes and
seconds fields
</entry>
! <entry><literal>make_interval(days := 10)</literal></entry>
<entry><literal>10 days</literal></entry>
</row>
--- 6785,6791 ----
Create interval from years, months, weeks, days, hours, minutes and
seconds fields
</entry>
! <entry><literal>make_interval(days => 10)</literal></entry>
<entry><literal>10 days</literal></entry>
</row>
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
new file mode 100644
index 4b81b08..d30db6a
*** a/doc/src/sgml/syntax.sgml
--- b/doc/src/sgml/syntax.sgml
*************** SELECT concat_lower_or_upper('Hello', 'W
*** 2599,2605 ****
<literal>:=</literal> to separate it from the argument expression.
For example:
<screen>
! SELECT concat_lower_or_upper(a := 'Hello', b := 'World');
concat_lower_or_upper
-----------------------
hello world
--- 2599,2605 ----
<literal>:=</literal> to separate it from the argument expression.
For example:
<screen>
! SELECT concat_lower_or_upper(a => 'Hello', b => 'World');
concat_lower_or_upper
-----------------------
hello world
*************** SELECT concat_lower_or_upper(a := 'Hello
*** 2610,2622 ****
using named notation is that the arguments may be specified in any
order, for example:
<screen>
! SELECT concat_lower_or_upper(a := 'Hello', b := 'World', uppercase := true);
concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
! SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
concat_lower_or_upper
-----------------------
HELLO WORLD
--- 2610,2633 ----
using named notation is that the arguments may be specified in any
order, for example:
<screen>
! SELECT concat_lower_or_upper(a => 'Hello', b => 'World', uppercase => true);
concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
! SELECT concat_lower_or_upper(a => 'Hello', uppercase => true, b => 'World');
! concat_lower_or_upper
! -----------------------
! HELLO WORLD
! (1 row)
! </screen>
! </para>
!
! <para>
! Older syntax based on ":=" symbol is still supported:
! <screen>
! SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
concat_lower_or_upper
-----------------------
HELLO WORLD
*************** SELECT concat_lower_or_upper(a := 'Hello
*** 2638,2644 ****
already mentioned, named arguments cannot precede positional arguments.
For example:
<screen>
! SELECT concat_lower_or_upper('Hello', 'World', uppercase := true);
concat_lower_or_upper
-----------------------
HELLO WORLD
--- 2649,2655 ----
already mentioned, named arguments cannot precede positional arguments.
For example:
<screen>
! SELECT concat_lower_or_upper('Hello', 'World', uppercase => true);
concat_lower_or_upper
-----------------------
HELLO WORLD
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
new file mode 100644
index f40504c..264e5ff
*** a/doc/src/sgml/xfunc.sgml
--- b/doc/src/sgml/xfunc.sgml
*************** SELECT mleast(VARIADIC ARRAY[]::numeric[
*** 776,789 ****
<literal>VARIADIC</>. For example, this will work:
<screen>
! SELECT mleast(VARIADIC arr := ARRAY[10, -1, 5, 4.4]);
</screen>
but not these:
<screen>
! SELECT mleast(arr := 10);
! SELECT mleast(arr := ARRAY[10, -1, 5, 4.4]);
</screen>
</para>
</sect2>
--- 776,789 ----
<literal>VARIADIC</>. For example, this will work:
<screen>
! SELECT mleast(VARIADIC arr => ARRAY[10, -1, 5, 4.4]);
</screen>
but not these:
<screen>
! SELECT mleast(arr => 10);
! SELECT mleast(arr => ARRAY[10, -1, 5, 4.4]);
</screen>
</para>
</sect2>
diff --git a/src/backend/commands/operatorcmds.c b/src/backend/commands/operatorcmds.c
new file mode 100644
index 2996019..e4327c2
*** a/src/backend/commands/operatorcmds.c
--- b/src/backend/commands/operatorcmds.c
*************** DefineOperator(List *names, List *parame
*** 87,102 ****
/* 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 may disallow it
- * as the name of a user-defined operator.
- */
- if (strcmp(oprName, "=>") == 0)
- ereport(WARNING,
- (errmsg("=> is deprecated as an operator name"),
- errdetail("This name may be disallowed altogether in future versions of PostgreSQL.")));
-
/* Check we have creation rights in target namespace */
aclresult = pg_namespace_aclcheck(oprNamespace, GetUserId(), ACL_CREATE);
if (aclresult != ACLCHECK_OK)
--- 87,92 ----
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
new file mode 100644
index 36dac29..6a02dcc
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
*************** static Node *makeRecursiveViewSelect(cha
*** 531,537 ****
*/
%token <str> IDENT FCONST SCONST BCONST XCONST Op
%token <ival> ICONST PARAM
! %token TYPECAST DOT_DOT COLON_EQUALS
/*
* If you want to make any keyword changes, update the keyword table in
--- 531,537 ----
*/
%token <str> IDENT FCONST SCONST BCONST XCONST Op
%token <ival> ICONST PARAM
! %token TYPECAST DOT_DOT COLON_EQUALS EQUALS_GREATER
/*
* If you want to make any keyword changes, update the keyword table in
*************** func_arg_expr: a_expr
*** 12552,12557 ****
--- 12552,12566 ----
{
NamedArgExpr *na = makeNode(NamedArgExpr);
na->name = $1;
+ na->arg = (Expr *) $3;
+ na->argnumber = -1; /* until determined */
+ na->location = @1;
+ $$ = (Node *) na;
+ }
+ | param_name EQUALS_GREATER a_expr
+ {
+ NamedArgExpr *na = makeNode(NamedArgExpr);
+ na->name = $1;
na->arg = (Expr *) $3;
na->argnumber = -1; /* until determined */
na->location = @1;
diff --git a/src/backend/parser/scan.l b/src/backend/parser/scan.l
new file mode 100644
index 21a6f30..743df71
*** a/src/backend/parser/scan.l
--- b/src/backend/parser/scan.l
*************** identifier {ident_start}{ident_cont}*
*** 334,339 ****
--- 334,340 ----
typecast "::"
dot_dot \.\.
colon_equals ":="
+ equals_greater "=>"
/*
* "self" is the set of chars that should be returned as single-character
*************** other .
*** 808,813 ****
--- 809,819 ----
return COLON_EQUALS;
}
+ {equals_greater} {
+ SET_YYLLOC();
+ return EQUALS_GREATER;
+ }
+
{self} {
SET_YYLLOC();
return yytext[0];
diff --git a/src/test/regress/expected/create_operator.out b/src/test/regress/expected/create_operator.out
new file mode 100644
index 2e6c764..3a216c2
*** a/src/test/regress/expected/create_operator.out
--- b/src/test/regress/expected/create_operator.out
*************** CREATE OPERATOR #%# (
*** 29,41 ****
-- Test comments
COMMENT ON OPERATOR ###### (int4, NONE) IS 'bad right unary';
ERROR: operator does not exist: integer ######
! -- Show deprecated message. => is deprecated now
CREATE OPERATOR => (
leftarg = int8, -- right unary
procedure = numeric_fac
);
! WARNING: => is deprecated as an operator name
! DETAIL: This name may be disallowed altogether in future versions of PostgreSQL.
-- Should fail. CREATE OPERATOR requires USAGE on SCHEMA
BEGIN TRANSACTION;
CREATE ROLE regress_rol_op1;
--- 29,42 ----
-- Test comments
COMMENT ON OPERATOR ###### (int4, NONE) IS 'bad right unary';
ERROR: operator does not exist: integer ######
! -- => is disallowed now
CREATE OPERATOR => (
leftarg = int8, -- right unary
procedure = numeric_fac
);
! ERROR: syntax error at or near "=>"
! LINE 1: CREATE OPERATOR => (
! ^
-- Should fail. CREATE OPERATOR requires USAGE on SCHEMA
BEGIN TRANSACTION;
CREATE ROLE regress_rol_op1;
diff --git a/src/test/regress/expected/polymorphism.out b/src/test/regress/expected/polymorphism.out
new file mode 100644
index 27b2879..987b3ee
*** a/src/test/regress/expected/polymorphism.out
--- b/src/test/regress/expected/polymorphism.out
*************** select dfunc('a'::text, 'b', flag := tru
*** 1356,1361 ****
--- 1356,1428 ----
a
(1 row)
+ -- ansi/sql syntax
+ select dfunc(a => 1, b => 2);
+ dfunc
+ -------
+ 1
+ (1 row)
+
+ select dfunc(a => 'a'::text, b => 'b');
+ dfunc
+ -------
+ a
+ (1 row)
+
+ select dfunc(a => 'a'::text, b => 'b', flag => false); -- named notation
+ dfunc
+ -------
+ b
+ (1 row)
+
+ select dfunc(b => 'b'::text, a => 'a'); -- named notation with default
+ dfunc
+ -------
+ a
+ (1 row)
+
+ select dfunc(a => 'a'::text, flag => true); -- named notation with default
+ dfunc
+ -------
+ a
+ (1 row)
+
+ select dfunc(a => 'a'::text, flag => false); -- named notation with default
+ dfunc
+ -------
+
+ (1 row)
+
+ select dfunc(b => 'b'::text, a => 'a', flag => true); -- named notation
+ dfunc
+ -------
+ a
+ (1 row)
+
+ select dfunc('a'::text, 'b', false); -- full positional notation
+ dfunc
+ -------
+ b
+ (1 row)
+
+ select dfunc('a'::text, 'b', flag => false); -- mixed notation
+ dfunc
+ -------
+ b
+ (1 row)
+
+ select dfunc('a'::text, 'b', true); -- full positional notation
+ dfunc
+ -------
+ a
+ (1 row)
+
+ select dfunc('a'::text, 'b', flag => true); -- mixed notation
+ dfunc
+ -------
+ a
+ (1 row)
+
-- check reverse-listing of named-arg calls
CREATE VIEW dfview AS
SELECT q1, q2,
diff --git a/src/test/regress/sql/create_operator.sql b/src/test/regress/sql/create_operator.sql
new file mode 100644
index f7a372a..0e5d635
*** a/src/test/regress/sql/create_operator.sql
--- b/src/test/regress/sql/create_operator.sql
*************** CREATE OPERATOR #%# (
*** 35,41 ****
-- Test comments
COMMENT ON OPERATOR ###### (int4, NONE) IS 'bad right unary';
! -- Show deprecated message. => is deprecated now
CREATE OPERATOR => (
leftarg = int8, -- right unary
procedure = numeric_fac
--- 35,41 ----
-- Test comments
COMMENT ON OPERATOR ###### (int4, NONE) IS 'bad right unary';
! -- => is disallowed now
CREATE OPERATOR => (
leftarg = int8, -- right unary
procedure = numeric_fac
diff --git a/src/test/regress/sql/polymorphism.sql b/src/test/regress/sql/polymorphism.sql
new file mode 100644
index 3d8dd1e..72f6cb5
*** a/src/test/regress/sql/polymorphism.sql
--- b/src/test/regress/sql/polymorphism.sql
*************** select dfunc('a'::text, 'b', flag := fal
*** 748,753 ****
--- 748,769 ----
select dfunc('a'::text, 'b', true); -- full positional notation
select dfunc('a'::text, 'b', flag := true); -- mixed notation
+ -- ansi/sql syntax
+ select dfunc(a => 1, b => 2);
+ select dfunc(a => 'a'::text, b => 'b');
+ select dfunc(a => 'a'::text, b => 'b', flag => false); -- named notation
+
+ select dfunc(b => 'b'::text, a => 'a'); -- named notation with default
+ select dfunc(a => 'a'::text, flag => true); -- named notation with default
+ select dfunc(a => 'a'::text, flag => false); -- named notation with default
+ select dfunc(b => 'b'::text, a => 'a', flag => true); -- named notation
+
+ select dfunc('a'::text, 'b', false); -- full positional notation
+ select dfunc('a'::text, 'b', flag => false); -- mixed notation
+ select dfunc('a'::text, 'b', true); -- full positional notation
+ select dfunc('a'::text, 'b', flag => true); -- mixed notation
+
+
-- check reverse-listing of named-arg calls
CREATE VIEW dfview AS
SELECT q1, q2,
On 19/01/15 17:14, Pavel Stehule wrote:
2015-01-19 14:27 GMT+01:00 Robert Haas <robertmhaas@gmail.com
<mailto:robertmhaas@gmail.com>>:On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule
<pavel.stehule@gmail.com <mailto:pavel.stehule@gmail.com>> wrote:I think you should just remove the WARNING, not change it to an error.
If somebody wants to quote the operator name to be able to continue
using it, I think that's OK.It looks so quoting doesn't help here
+ CREATE OPERATOR "=>" ( + leftarg = int8,<--><------>-- right unary + procedure = numeric_fac + ); + ERROR: syntax error at or near "(" + LINE 1: CREATE OPERATOR "=>" ( + ^Well then the error check is just dead code. Either way, you don't
need it.yes, I removed it
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.
The "=>" operator was deprecated for several years so it should not be
too controversial either.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-02-19 16:06 GMT+01:00 Petr Jelinek <petr@2ndquadrant.com>:
On 19/01/15 17:14, Pavel Stehule wrote:
2015-01-19 14:27 GMT+01:00 Robert Haas <robertmhaas@gmail.com
<mailto:robertmhaas@gmail.com>>:On Mon, Jan 19, 2015 at 2:59 AM, Pavel Stehule
<pavel.stehule@gmail.com <mailto:pavel.stehule@gmail.com>> wrote:I think you should just remove the WARNING, not change it to an
error.
If somebody wants to quote the operator name to be able to continue
using it, I think that's OK.It looks so quoting doesn't help here
+ CREATE OPERATOR "=>" ( + leftarg = int8,<--><------>-- right unary + procedure = numeric_fac + ); + ERROR: syntax error at or near "(" + LINE 1: CREATE OPERATOR "=>" ( + ^Well then the error check is just dead code. Either way, you don't
need it.yes, I removed it
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.The "=>" operator was deprecated for several years so it should not be too
controversial either.
Thank you very much
Pavel
Show quoted text
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.The "=>" operator was deprecated for several years so it should not be too
controversial either.
Committed with a few documentation tweaks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.The "=>" operator was deprecated for several years so it should not be too
controversial either.
Committed with a few documentation tweaks.
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with "=>"? Or do we think that needs to wait?
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
2015-03-10 16:50 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.The "=>" operator was deprecated for several years so it should not be
too
controversial either.
Committed with a few documentation tweaks.
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with "=>"? Or do we think that needs to wait?
I didn't think about it? I don't see any reason why it have to use
deprecated syntax.
Regards
Pavel
Show quoted text
regards, tom lane
On 10/03/15 17:01, Pavel Stehule wrote:
2015-03-10 16:50 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>:Robert Haas <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>
writes:Committed with a few documentation tweaks.
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with "=>"? Or do we think that needs to wait?I didn't think about it? I don't see any reason why it have to use
deprecated syntax.
There is one, loading the output into older version of Postgres. Don't
know if that's important one though.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-03-10 17:07 GMT+01:00 Petr Jelinek <petr@2ndquadrant.com>:
On 10/03/15 17:01, Pavel Stehule wrote:
2015-03-10 16:50 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>:Robert Haas <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>
writes:Committed with a few documentation tweaks.
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with "=>"? Or do we think that needs to wait?I didn't think about it? I don't see any reason why it have to use
deprecated syntax.There is one, loading the output into older version of Postgres. Don't
know if that's important one though.
I don't think so it is a hard issue. We doesn't support downgrades - and if
somebody needs it, it can fix it with some regexp. We should to use
preferred syntax everywhere - and preferred syntax should be ANSI.
I forgot it :(
Pavel
Show quoted text
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Mar 10, 2015 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.The "=>" operator was deprecated for several years so it should not be too
controversial either.Committed with a few documentation tweaks.
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with "=>"? Or do we think that needs to wait?
I have to admit that I didn't consider that. What do you think? I
guess I'd be tentatively in favor of changing that to match, but I
could be convinced otherwise.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Mar 10, 2015 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with "=>"? Or do we think that needs to wait?
I have to admit that I didn't consider that. What do you think? I
guess I'd be tentatively in favor of changing that to match, but I
could be convinced otherwise.
Well, as said upthread, the argument for not changing would be that it
would make it easier to dump views and reload them into older PG versions.
I'm not sure how big a consideration that is, or whether it outweighs
possible cross-DBMS compatibility benefits of dumping the more standard
syntax. Presumably we are going to change it at some point; maybe we
should just do it rather than waiting another 5 years.
IOW, I guess I lean mildly towards changing, but I've been beaten up
enough lately about backwards-compatibility worries that I'm not going
to fight for changing this.
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
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Mar 10, 2015 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with "=>"? Or do we think that needs to wait?I have to admit that I didn't consider that. What do you think? I
guess I'd be tentatively in favor of changing that to match, but I
could be convinced otherwise.
Presumably we are going to change it at some point; maybe we
should just do it rather than waiting another 5 years.
+1
It has been deprecated long enough that I don't see the point of waiting.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kevin Grittner <kgrittn@ymail.com> writes:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Presumably we are going to change it at some point; maybe we
should just do it rather than waiting another 5 years.
+1
It has been deprecated long enough that I don't see the point of waiting.
Uh, just to clarify, this has nothing to do with how long the operator has
been deprecated. The issue is whether pg_dump should dump a function-call
syntax that will not be recognized by any pre-9.5 release, when there is
an alternative that will be recognized back to 9.0.
BTW, I just noticed another place that probably should be changed:
regression=# select foo(x => 1);
ERROR: 42883: function foo(x := integer) does not exist
LINE 1: select foo(x => 1);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
LOCATION: ParseFuncOrColumn, parse_func.c:516
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
2015-03-10 19:02 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Kevin Grittner <kgrittn@ymail.com> writes:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Presumably we are going to change it at some point; maybe we
should just do it rather than waiting another 5 years.+1
It has been deprecated long enough that I don't see the point of waiting.
Uh, just to clarify, this has nothing to do with how long the operator has
been deprecated. The issue is whether pg_dump should dump a function-call
syntax that will not be recognized by any pre-9.5 release, when there is
an alternative that will be recognized back to 9.0.BTW, I just noticed another place that probably should be changed:
regression=# select foo(x => 1);
ERROR: 42883: function foo(x := integer) does not exist
LINE 1: select foo(x => 1);
^
HINT: No function matches the given name and argument types. You might
need to add explicit type casts.
LOCATION: ParseFuncOrColumn, parse_func.c:516
1. funcname_signature_string
2. get_rule_expr
Show quoted text
regards, tom lane
On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
1. funcname_signature_string
2. get_rule_expr
Thanks. Patch attached. I'll commit this if there are no objections.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
named-expr-fixes.patchbinary/octet-stream; name=named-expr-fixes.patchDownload
diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index a200804..3f4417f 100644
--- a/src/backend/parser/parse_func.c
+++ b/src/backend/parser/parse_func.c
@@ -1853,7 +1853,7 @@ funcname_signature_string(const char *funcname, int nargs,
appendStringInfoString(&argbuf, ", ");
if (i >= numposargs)
{
- appendStringInfo(&argbuf, "%s := ", (char *) lfirst(lc));
+ appendStringInfo(&argbuf, "%s => ", (char *) lfirst(lc));
lc = lnext(lc);
}
appendStringInfoString(&argbuf, format_type_be(argtypes[i]));
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c
index 2fa30be..f8ef5b6 100644
--- a/src/backend/utils/adt/ruleutils.c
+++ b/src/backend/utils/adt/ruleutils.c
@@ -6827,7 +6827,7 @@ get_rule_expr(Node *node, deparse_context *context,
{
NamedArgExpr *na = (NamedArgExpr *) node;
- appendStringInfo(buf, "%s := ", quote_identifier(na->name));
+ appendStringInfo(buf, "%s => ", quote_identifier(na->name));
get_rule_expr((Node *) na->arg, context, showimplicit);
}
break;
diff --git a/src/test/regress/expected/polymorphism.out b/src/test/regress/expected/polymorphism.out
index 987b3ee..ddf45cf 100644
--- a/src/test/regress/expected/polymorphism.out
+++ b/src/test/regress/expected/polymorphism.out
@@ -1124,17 +1124,17 @@ ERROR: positional argument cannot follow named argument
LINE 1: select * from dfunc(10, b := 20, 30);
^
select * from dfunc(x := 10, b := 20, c := 30); -- fail, unknown param
-ERROR: function dfunc(x := integer, b := integer, c := integer) does not exist
+ERROR: function dfunc(x => integer, b => integer, c => integer) does not exist
LINE 1: select * from dfunc(x := 10, b := 20, c := 30);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
select * from dfunc(10, 10, a := 20); -- fail, a overlaps positional parameter
-ERROR: function dfunc(integer, integer, a := integer) does not exist
+ERROR: function dfunc(integer, integer, a => integer) does not exist
LINE 1: select * from dfunc(10, 10, a := 20);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
select * from dfunc(1,c := 2,d := 3); -- fail, no value for b
-ERROR: function dfunc(integer, c := integer, d := integer) does not exist
+ERROR: function dfunc(integer, c => integer, d => integer) does not exist
LINE 1: select * from dfunc(1,c := 2,d := 3);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
@@ -1175,7 +1175,7 @@ select * from dfunc('Hello World', c := '2009-07-25'::date, b := 20);
(1 row)
select * from dfunc('Hello World', c := 20, b := '2009-07-25'::date); -- fail
-ERROR: function dfunc(unknown, c := integer, b := date) does not exist
+ERROR: function dfunc(unknown, c => integer, b => date) does not exist
LINE 1: select * from dfunc('Hello World', c := 20, b := '2009-07-25...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
@@ -1450,8 +1450,8 @@ select * from dfview;
View definition:
SELECT int8_tbl.q1,
int8_tbl.q2,
- dfunc(int8_tbl.q1, int8_tbl.q2, flag := int8_tbl.q1 > int8_tbl.q2) AS c3,
- dfunc(int8_tbl.q1, flag := int8_tbl.q1 < int8_tbl.q2, b := int8_tbl.q2) AS c4
+ dfunc(int8_tbl.q1, int8_tbl.q2, flag => int8_tbl.q1 > int8_tbl.q2) AS c3,
+ dfunc(int8_tbl.q1, flag => int8_tbl.q1 < int8_tbl.q2, b => int8_tbl.q2) AS c4
FROM int8_tbl;
drop view dfview;
On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote:
On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
1. funcname_signature_string
2. get_rule_exprThanks. Patch attached. I'll commit this if there are no objections.
Robert, are you going to apply this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
It is done
Dne 1.5.2015 3:11 napsal uživatel "Bruce Momjian" <bruce@momjian.us>:
Show quoted text
On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote:
On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:
1. funcname_signature_string
2. get_rule_exprThanks. Patch attached. I'll commit this if there are no objections.
Robert, are you going to apply this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com+ Everyone has their own god. +
On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
It is done
Uh, I am not sure why you say that as I don't see any commit related to
this. Can you show me the commit?
---------------------------------------------------------------------------
Dne 1.5.2015 3:11 napsal uživatel "Bruce Momjian" <bruce@momjian.us>:
On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote:
On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:
1. funcname_signature_string
2. get_rule_exprThanks. Patch attached. I'll commit this if there are no objections.
Robert, are you going to apply this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com+ Everyone has their own god. +
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/05/15 15:01, Bruce Momjian wrote:
On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
It is done
Uh, I am not sure why you say that as I don't see any commit related to
this. Can you show me the commit?
865f14a2d31af23a05bbf2df04c274629c5d5c4d
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 1, 2015 at 03:13:28PM +0200, Petr Jelinek wrote:
On 01/05/15 15:01, Bruce Momjian wrote:
On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
It is done
Uh, I am not sure why you say that as I don't see any commit related to
this. Can you show me the commit?865f14a2d31af23a05bbf2df04c274629c5d5c4d
But that doesn't touch these:
1. funcname_signature_string
2. get_rule_expr
which is what Robert's later patch did:
/messages/by-id/CA+TgmobCMF7F50+feJpcLR8E_Lyv45AYXBSdiog-NS7VLuFopg@mail.gmail.com
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/05/15 15:17, Bruce Momjian wrote:
On Fri, May 1, 2015 at 03:13:28PM +0200, Petr Jelinek wrote:
On 01/05/15 15:01, Bruce Momjian wrote:
On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
It is done
Uh, I am not sure why you say that as I don't see any commit related to
this. Can you show me the commit?865f14a2d31af23a05bbf2df04c274629c5d5c4d
But that doesn't touch these:
1. funcname_signature_string
2. get_rule_exprwhich is what Robert's later patch did:
/messages/by-id/CA+TgmobCMF7F50+feJpcLR8E_Lyv45AYXBSdiog-NS7VLuFopg@mail.gmail.com
Oh, now I see what you mean, yeah that does not appear to have been
committed.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Apr 30, 2015 at 9:11 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote:
On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
1. funcname_signature_string
2. get_rule_exprThanks. Patch attached. I'll commit this if there are no objections.
Robert, are you going to apply this?
Good catch. I had totally forgotten about this. Committed now, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers