pgsql: Add missing keywords to gram.y's unreserved_keywords list.
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using existing keywords?
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/3f7d24da16d32ad0fa5abf04b669e86a7d458160
Modified Files
--------------
src/backend/parser/gram.y | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using existing keywords?
I think we ought to try to do something about this, so that VALIDATE
doesn't need to become a keyword.
How about instead of VALIDATE CONSTRAINT we simply write ALTER
CONSTRAINT ... VALID? (Patch attached, passes make check.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
alter-constraint-valid.patchapplication/octet-stream; name=alter-constraint-valid.patchDownload
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index c194862..16c34bf 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -45,7 +45,7 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable>
ADD <replaceable class="PARAMETER">table_constraint</replaceable>
ADD <replaceable class="PARAMETER">table_constraint_using_index</replaceable>
ADD <replaceable class="PARAMETER">table_constraint</replaceable> [ NOT VALID ]
- VALIDATE CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable>
+ ALTER CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable> VALID
DROP CONSTRAINT [ IF EXISTS ] <replaceable class="PARAMETER">constraint_name</replaceable> [ RESTRICT | CASCADE ]
DISABLE TRIGGER [ <replaceable class="PARAMETER">trigger_name</replaceable> | ALL | USER ]
ENABLE TRIGGER [ <replaceable class="PARAMETER">trigger_name</replaceable> | ALL | USER ]
@@ -248,7 +248,7 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable>
</varlistentry>
<varlistentry>
- <term><literal>VALIDATE CONSTRAINT</literal></term>
+ <term><literal>ALTER CONSTRAINT <replaceable class="PARAMTER">constraint_name</replaceable> VALID</literal></term>
<listitem>
<para>
This form validates a foreign key constraint that was previously created
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index f1264bf..38483fa 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -5642,7 +5642,7 @@ ATAddForeignKeyConstraint(AlteredTableInfo *tab, Relation rel,
}
/*
- * ALTER TABLE VALIDATE CONSTRAINT
+ * ALTER TABLE ALTER CONSTRAINT VALID
*/
static void
ATExecValidateConstraint(Relation rel, const char *constrName)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 373d2ad..927fef0 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -556,7 +556,7 @@ static void SplitColQualList(List *qualList,
UNBOUNDED UNCOMMITTED UNENCRYPTED UNION UNIQUE UNKNOWN UNLISTEN UNLOGGED
UNTIL UPDATE USER USING
- VACUUM VALID VALIDATE VALIDATOR VALUE_P VALUES VARCHAR VARIADIC VARYING
+ VACUUM VALID VALIDATOR VALUE_P VALUES VARCHAR VARIADIC VARYING
VERBOSE VERSION_P VIEW VOLATILE
WHEN WHERE WHITESPACE_P WINDOW WITH WITHOUT WORK WRAPPER WRITE
@@ -1770,8 +1770,8 @@ alter_table_cmd:
n->def = $2;
$$ = (Node *)n;
}
- /* ALTER TABLE <name> VALIDATE CONSTRAINT ... */
- | VALIDATE CONSTRAINT name
+ /* ALTER TABLE <name> ALTER CONSTRAINT ... VALID */
+ | ALTER CONSTRAINT name VALID
{
AlterTableCmd *n = makeNode(AlterTableCmd);
n->subtype = AT_ValidateConstraint;
@@ -12057,7 +12057,6 @@ unreserved_keyword:
| UPDATE
| VACUUM
| VALID
- | VALIDATE
| VALIDATOR
| VALUE_P
| VARYING
diff --git a/src/include/parser/kwlist.h b/src/include/parser/kwlist.h
index f288c76..c1a1686 100644
--- a/src/include/parser/kwlist.h
+++ b/src/include/parser/kwlist.h
@@ -399,7 +399,6 @@ PG_KEYWORD("user", USER, RESERVED_KEYWORD)
PG_KEYWORD("using", USING, RESERVED_KEYWORD)
PG_KEYWORD("vacuum", VACUUM, UNRESERVED_KEYWORD)
PG_KEYWORD("valid", VALID, UNRESERVED_KEYWORD)
-PG_KEYWORD("validate", VALIDATE, UNRESERVED_KEYWORD)
PG_KEYWORD("validator", VALIDATOR, UNRESERVED_KEYWORD)
PG_KEYWORD("value", VALUE_P, UNRESERVED_KEYWORD)
PG_KEYWORD("values", VALUES, COL_NAME_KEYWORD)
diff --git a/src/test/regress/expected/alter_table.out b/src/test/regress/expected/alter_table.out
index d5a59d5..0c24d70 100644
--- a/src/test/regress/expected/alter_table.out
+++ b/src/test/regress/expected/alter_table.out
@@ -186,16 +186,16 @@ DELETE FROM tmp3 where a=5;
ALTER TABLE tmp3 add constraint tmpconstr foreign key (a) references tmp2 match full;
ALTER TABLE tmp3 drop constraint tmpconstr;
INSERT INTO tmp3 values (5,50);
--- Try NOT VALID and then VALIDATE CONSTRAINT, but fails. Delete failure then re-validate
+-- Try NOT VALID and then ALTER CONSTRAINT VALID, but fails. Delete failure then re-validate
ALTER TABLE tmp3 add constraint tmpconstr foreign key (a) references tmp2 match full NOT VALID;
-ALTER TABLE tmp3 validate constraint tmpconstr;
+ALTER TABLE tmp3 alter constraint tmpconstr valid;
ERROR: insert or update on table "tmp3" violates foreign key constraint "tmpconstr"
DETAIL: Key (a)=(5) is not present in table "tmp2".
-- Delete failing row
DELETE FROM tmp3 where a=5;
-- Try (and succeed) and repeat to show it works on already valid constraint
-ALTER TABLE tmp3 validate constraint tmpconstr;
-ALTER TABLE tmp3 validate constraint tmpconstr;
+ALTER TABLE tmp3 alter constraint tmpconstr valid;
+ALTER TABLE tmp3 alter constraint tmpconstr valid;
-- Try (and fail) to create constraint from tmp5(a) to tmp4(a) - unique constraint on
-- tmp4 is a,b
ALTER TABLE tmp5 add constraint tmpconstr foreign key(a) references tmp4(a) match full;
diff --git a/src/test/regress/sql/alter_table.sql b/src/test/regress/sql/alter_table.sql
index 6531a9f..af62fa6 100644
--- a/src/test/regress/sql/alter_table.sql
+++ b/src/test/regress/sql/alter_table.sql
@@ -225,16 +225,16 @@ ALTER TABLE tmp3 drop constraint tmpconstr;
INSERT INTO tmp3 values (5,50);
--- Try NOT VALID and then VALIDATE CONSTRAINT, but fails. Delete failure then re-validate
+-- Try NOT VALID and then ALTER CONSTRAINT VALID, but fails. Delete failure then re-validate
ALTER TABLE tmp3 add constraint tmpconstr foreign key (a) references tmp2 match full NOT VALID;
-ALTER TABLE tmp3 validate constraint tmpconstr;
+ALTER TABLE tmp3 alter constraint tmpconstr valid;
-- Delete failing row
DELETE FROM tmp3 where a=5;
-- Try (and succeed) and repeat to show it works on already valid constraint
-ALTER TABLE tmp3 validate constraint tmpconstr;
-ALTER TABLE tmp3 validate constraint tmpconstr;
+ALTER TABLE tmp3 alter constraint tmpconstr valid;
+ALTER TABLE tmp3 alter constraint tmpconstr valid;
-- Try (and fail) to create constraint from tmp5(a) to tmp4(a) - unique constraint on
Excerpts from Robert Haas's message of vie mar 11 15:59:40 -0300 2011:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using existing keywords?I think we ought to try to do something about this, so that VALIDATE
doesn't need to become a keyword.How about instead of VALIDATE CONSTRAINT we simply write ALTER
CONSTRAINT ... VALID? (Patch attached, passes make check.)
Please make-check the docs too.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using existing keywords?I think we ought to try to do something about this, so that VALIDATE
doesn't need to become a keyword.How about instead of VALIDATE CONSTRAINT we simply write ALTER
CONSTRAINT ... VALID? (Patch attached, passes make check.)
ALTER CONSTRAINT ... VALID sounds like it just marks the constraint as
valid. "VALIDATE CONSTRAINT" sounds like it scans and checks that the
constraint is valid.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using existing keywords?I think we ought to try to do something about this, so that VALIDATE
doesn't need to become a keyword.How about instead of VALIDATE CONSTRAINT we simply write ALTER
CONSTRAINT ... VALID? (Patch attached, passes make check.)ALTER CONSTRAINT ... VALID sounds like it just marks the constraint as
valid. "VALIDATE CONSTRAINT" sounds like it scans and checks that the
constraint is valid.
Yeah, it's a little awkward, but I think it's still better than adding
another keyword. Any other ideas for wording?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mar 11, 2011, at 1:40 PM, Robert Haas wrote:
On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using existing keywords?I think we ought to try to do something about this, so that VALIDATE
doesn't need to become a keyword.How about instead of VALIDATE CONSTRAINT we simply write ALTER
CONSTRAINT ... VALID? (Patch attached, passes make check.)ALTER CONSTRAINT ... VALID sounds like it just marks the constraint as
valid. "VALIDATE CONSTRAINT" sounds like it scans and checks that the
constraint is valid.Yeah, it's a little awkward, but I think it's still better than adding
another keyword. Any other ideas for wording?
CHECK VALID?
Regards,
David
--
David Christensen
End Point Corporation
david@endpoint.com
On 03/11/2011 02:50 PM, David Christensen wrote:
On Mar 11, 2011, at 1:40 PM, Robert Haas wrote:
On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using existing keywords?I think we ought to try to do something about this, so that VALIDATE
doesn't need to become a keyword.How about instead of VALIDATE CONSTRAINT we simply write ALTER
CONSTRAINT ... VALID? (Patch attached, passes make check.)ALTER CONSTRAINT ... VALID sounds like it just marks the constraint as
valid. "VALIDATE CONSTRAINT" sounds like it scans and checks that the
constraint is valid.Yeah, it's a little awkward, but I think it's still better than adding
another keyword. Any other ideas for wording?CHECK VALID?
SET VALID? (c.f. SET NULL).
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 03/11/2011 02:50 PM, David Christensen wrote:
On Mar 11, 2011, at 1:40 PM, Robert Haas wrote:
ALTER CONSTRAINT ... VALID sounds like it just marks the constraint as
valid. "VALIDATE CONSTRAINT" sounds like it scans and checks that the
constraint is valid.
SET VALID? (c.f. SET NULL).
That sounds the best so far, but maybe we should think about other
phrases altogether (ie, not arising from the word "valid")? I don't
have any great ideas offhand, just trying to think outside the box.
regards, tom lane
On 03/11/2011 02:56 PM, Andrew Dunstan wrote:
SET VALID? (c.f. SET NULL).
Of course I mean SET NOT NULL.
Anyway, the full thing would be something like
ALTER TABLE foo SET VALID CONSTRAINT bar;
cheers
andrew
On Fri, Mar 11, 2011 at 3:00 PM, Andrew Dunstan <adunstan@postgresql.org> wrote:
On 03/11/2011 02:56 PM, Andrew Dunstan wrote:
SET VALID? (c.f. SET NULL).
Of course I mean SET NOT NULL.
Anyway, the full thing would be something like
ALTER TABLE foo SET VALID CONSTRAINT bar;
Or ALTER TABLE foo SET CONSTRAINT bar VALID
Or ALTER TABLE foo ALTER CONSTRAINT bar SET VALID
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
SET VALID? (c.f. SET NULL).
That sounds the best so far, but maybe we should think about other
phrases altogether (ie, not arising from the word "valid")? I
don't have any great ideas offhand, just trying to think outside
the box.
At the risk of adding yet another meaning to an
already-heavily-worked word, ANALYZE?
-Kevin
On Fri, Mar 11, 2011 at 3:10 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
SET VALID? (c.f. SET NULL).
That sounds the best so far, but maybe we should think about other
phrases altogether (ie, not arising from the word "valid")? I
don't have any great ideas offhand, just trying to think outside
the box.At the risk of adding yet another meaning to an
already-heavily-worked word, ANALYZE?
Well, we don't seem to really have consensus around anything in
particular here. Should we just leave it alone, or is this worth
spending more effort on?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
Well, we don't seem to really have consensus around anything in
particular here. Should we just leave it alone, or is this worth
spending more effort on?
I haven't seen any suggestions yet that don't seem inferior to the
existing command name (ie, VALIDATE). I'm inclined to leave it alone.
Your recent hack on CREATE ROLE bought more than changing this would.
regards, tom lane