Re: [HACKERS] updatable views and default values
On Sat, Sep 02, 2006 at 06:22:49PM -0500, Jim C. Nasby wrote: On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote: For backwards compatibility we should probably say that this automatic lifting of base-table defaults happens only if the INSERT rule is implicitly generated ... if you write a manual INSERT rule you need manual defaults too. Or should propagate default values become an explicit attribute of ON INSERT rules? ISTM that least surprise dictates that inserting into a view uses the base table default unless you specifically override them. +1 :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] updatable views and default values
On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote: For backwards compatibility we should probably say that this automatic lifting of base-table defaults happens only if the INSERT rule is implicitly generated ... if you write a manual INSERT rule you need manual defaults too. Or should propagate default values become an explicit attribute of ON INSERT rules? ISTM that least surprise dictates that inserting into a view uses the base table default unless you specifically override them. -- Jim C. Nasby, Database Architect [EMAIL PROTECTED] 512.569.9461 (cell) http://jim.nasby.net ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] updatable views and default values
Jaime Casanova [EMAIL PROTECTED] writes: now that you're reviewing the updatable view patch, i think we must decide what you're position will be about if the updatable view should inherit the base table default values... or if we want to create default values for every view if we want they match with the base table ones... (fwiw, informix does the former) I'm inclined to agree that if we create an automatic INSERT rule for a view, we ought to automatically copy the base table's defaults up to the view as well. Otherwise the user will certainly want to do that by hand, and the whole point of this feature is to eliminate the need to do obvious things by hand. I think that this would require adding a flag to pg_attrdef entries to show whether they were created implicitly or not, so that pg_dump would know not to dump them. But wait, what if the user does ALTER SET DEFAULT on the base table --- shouldn't that then propagate to the view? Perhaps it would be better if the implementation didn't explicitly store a default expression attached to the view, but were willing to drill down to the base table and grab its default. You could still override that by explicitly attaching a different default to the view, but 90% of the time this would be the right thing. For backwards compatibility we should probably say that this automatic lifting of base-table defaults happens only if the INSERT rule is implicitly generated ... if you write a manual INSERT rule you need manual defaults too. Or should propagate default values become an explicit attribute of ON INSERT rules? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Updatable views
Alvaro Herrera wrote: Hi, Is anybody working on Bernd's updatable views patch? Right now I'm having a look at it -- mainly fixing some cosmetic issues right now, intending to eventually do an actual code review. I'll post an updated patch at some point -- if someone wants to have a look or do some intensive review, just ask and I'll send whatever I have. Great. You have been a big help in the past in reviewing patches during feature freeze. Also Neil used to help too. I have talked to Tom and he knows the outstanding patches that are out there. I am going through the less visible ones and hope to put up an outstanding patch list in the next week, but if you are going to be involved too, I will try to do it sooner. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Updatable views
Alvaro Herrera [EMAIL PROTECTED] writes: Is anybody working on Bernd's updatable views patch? Right now I'm having a look at it -- mainly fixing some cosmetic issues right now, intending to eventually do an actual code review. Great --- it's on my to-do list but I'm happy to have more eyeballs on it. My advice is to look first for showstoppers: is there anything fundamentally wrong/broken? With something like this it's not at all unlikely that the basic approach doesn't really work. I'll post an updated patch at some point -- if someone wants to have a look or do some intensive review, just ask and I'll send whatever I have. No hurry from me; I've got a lot of other things to look at too, so I'll just drop this one back towards the end of the list. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Updatable views/with check option parsing
While I don't think that making WITH a fully reserved word would cause any great damage, I'm unwilling to do it just to save a couple of lines of code. I think we should go on and do promote WITH to a reserved keyword now Oracle, MS-SQL, DB2, MySQL and Informix also have WITH reserved, so it would imho be ok to do it if it simplifies code. Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Updatable views/with check option parsing
Ühel kenal päeval, R, 2006-05-26 kell 22:50, kirjutas Tom Lane: I wrote: We can use the same technique that we used for UNION JOIN, but instead join, say, WITH and TIME into one token and make the time datatype productions look for TIME WITHTIME ZONE and so on. (I propose this rather than putting the ugliness into WITH CHECK OPTION, because this way we should only need one merged token and thus only one case to check in the filter function; AFAICS we'd need three cases if we merge tokens on that end of it.) On investigation that turns out to have been a bad idea: if we do it that way, it becomes necessary to promote WITH to a fully reserved word. The counterexample is CREATE VIEW v AS SELECT * FROM foo WITH ... Is WITH an alias for foo (with no AS), or is it the start of a WITH CHECK OPTION? No way to tell without lookahead. While I don't think that making WITH a fully reserved word would cause any great damage, I'm unwilling to do it just to save a couple of lines of code. I think we should go on and do promote WITH to a reserved keyword now because eventually we have to do it anyway. It is needed for recursive queries as well. I don't pretend to be an expert bison coder, but I was unable to define a grammar for SQL-standard recursive queries without making WITH a reserved keyword. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Updatable views/with check option parsing
Hannu Krosing [EMAIL PROTECTED] writes: I think we should go on and do promote WITH to a reserved keyword now because eventually we have to do it anyway. It is needed for recursive queries as well. I'm unconvinced. Recursive queries have WITH at the front, not the back, so the parsing issues are entirely different. If we do find that, we can easily adjust this code to simplify the filter function at that time. But I don't agree with reserving words just because we might need them for patches that don't exist yet. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Updatable views/with check option parsing
Am Mittwoch, 24. Mai 2006 20:42 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
I have spent some time figuring out how to resolve the parsing conflicts
in Bernd Helmle's updatable views patch. The problem has now been
reduced to specifically this situation:
Could we see the proposed patches for gram.y?
Here it is.
$ make -W gram.y gram.c
bison -y -d gram.y
conflicts: 4 shift/reduce
These are basically for instances of the same problem.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
--- /home/pei/devel/pg82/pgsql/src/backend/parser/gram.y 2006-05-22 09:05:13.0 +0200
+++ gram.y 2006-05-26 09:41:21.0 +0200
@@ -339,7 +339,8 @@
%type list constraints_set_list
%type boolean constraints_set_mode
%type str OptTableSpace OptConsTableSpace OptTableSpaceOwner
-
+%type listopt_check_option
+%type nodeopt_check_mode
/*
* If you make any token changes, update the keyword table in
@@ -356,7 +357,7 @@
BACKWARD BEFORE BEGIN_P BETWEEN BIGINT BINARY BIT
BOOLEAN_P BOTH BY
- CACHE CALLED CASCADE CASE CAST CHAIN CHAR_P
+ CACHE CALLED CASCADE CASCADED CASE CAST CHAIN CHAR_P
CHARACTER CHARACTERISTICS CHECK CHECKPOINT CLASS CLOSE
CLUSTER COALESCE COLLATE COLUMN COMMENT COMMIT
COMMITTED CONNECTION CONSTRAINT CONSTRAINTS CONVERSION_P CONVERT COPY CREATE CREATEDB
@@ -4618,12 +4619,12 @@
/*
*
* QUERY:
- * CREATE [ OR REPLACE ] [ TEMP ] VIEW viewname '('target-list ')' AS query
+ * CREATE [ OR REPLACE ] [ TEMP ] VIEW viewname '('target-list ')' AS query [ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
*
*/
ViewStmt: CREATE OptTemp VIEW qualified_name opt_column_list
-AS SelectStmt
+AS SelectStmt opt_check_option
{
ViewStmt *n = makeNode(ViewStmt);
n-replace = false;
@@ -4631,10 +4632,11 @@
n-view-istemp = $2;
n-aliases = $5;
n-query = (Query *) $7;
+ n-options = (List *) $8;
$$ = (Node *) n;
}
| CREATE OR REPLACE OptTemp VIEW qualified_name opt_column_list
-AS SelectStmt
+AS SelectStmt opt_check_option
{
ViewStmt *n = makeNode(ViewStmt);
n-replace = true;
@@ -4642,10 +4644,25 @@
n-view-istemp = $4;
n-aliases = $7;
n-query = (Query *) $9;
+ n-options = (List *) $10;
$$ = (Node *) n;
}
;
+opt_check_option:
+WITH opt_check_mode CHECK OPTION
+ {
+ $$ = list_make1( $2 );
+}
+ | /* EMPTY */ { $$ = NIL; }
+;
+
+opt_check_mode:
+CASCADED { $$ = (Node *)makeString(cascaded); }
+| LOCAL { $$ = (Node *)makeString(local); }
+| /* EMPTY */ { $$ = (Node *)makeString(cascaded); }
+ ;
+
/*
*
* QUERY:
@@ -8500,7 +8517,6 @@
| VARYING
| VIEW
| VOLATILE
- | WITH
| WITHOUT
| WORK
| WRITE
@@ -8551,8 +8567,6 @@
| SETOF
| SMALLINT
| SUBSTRING
- | TIME
- | TIMESTAMP
| TREAT
| TRIM
| VARCHAR
@@ -8608,6 +8622,7 @@
| ASC
| ASYMMETRIC
| BOTH
+ | CASCADED
| CASE
| CAST
| CHECK
@@ -8662,6 +8677,8 @@
| SYMMETRIC
| TABLE
| THEN
+ | TIME
+ | TIMESTAMP
| TO
| TRAILING
| TRUE_P
@@ -8671,6 +8688,7 @@
| USING
| WHEN
| WHERE
+ | WITH
;
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Updatable views/with check option parsing
Peter Eisentraut wrote: Am Mittwoch, 24. Mai 2006 20:42 schrieb Tom Lane: Peter Eisentraut [EMAIL PROTECTED] writes: I have spent some time figuring out how to resolve the parsing conflicts in Bernd Helmle's updatable views patch. The problem has now been reduced to specifically this situation: Could we see the proposed patches for gram.y? Here it is. $ make -W gram.y gram.c bison -y -d gram.y conflicts: 4 shift/reduce These are basically for instances of the same problem. I had a quick look - I don't think there is an easy answer with the current proposed grammar. If we want to prevent shift/reduce conflicts I suspect we'd need to use a different keyword than WITH, although I can't think of one that couldn't be a trailing clause on a select statment, which is the cause of the trouble. Another possibility would be to move the optional WITH clause so that it would come before the AS clause. Then there should be no conflict, I believe. Something like: ViewStmt: CREATE OptTemp VIEW qualified_name opt_column_list opt_check_option AS SelectStmt cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Updatable views/with check option parsing
Andrew Dunstan [EMAIL PROTECTED] writes: I had a quick look - I don't think there is an easy answer with the current proposed grammar. If we want to prevent shift/reduce conflicts I suspect we'd need to use a different keyword than WITH, although I can't think of one that couldn't be a trailing clause on a select statment, which is the cause of the trouble. Another possibility would be to move the optional WITH clause so that it would come before the AS clause. Unfortunately the SQL99 spec is perfectly clear about what it wants: view definition ::= CREATE [ RECURSIVE ] VIEW table name view specification AS query expression [ WITH [ levels clause ] CHECK OPTION ] levels clause ::= CASCADED | LOCAL I haven't had time to play with this yet, but I suspect the answer will have to be that we reinstate the token-merging UNION JOIN kluge that I just took out :-(. Or we could look into recognizing the whole thing as one token in scan.l, but I suspect that doesn't work unless we give up the no-backtrack property of the lexer, which would be more of a speed hit than the intermediate function was. Anyway it should certainly be soluble with token merging, if we can't find a pure grammar solution. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Updatable views/with check option parsing
On Wed, May 24, 2006 at 01:13:06PM +0200, Peter Eisentraut wrote: CREATE VIEW foo AS SELECT expr :: TIME . WITH (where expr is a_expr or b_expr and TIME could also be TIMESTAMP or TIME(x) or TIMESTAMP(x)). The continuation here could be WITH TIME ZONE (calling for a shift) or WITH CHECK OPTION (calling for a reduce). All the usual ideas about unfolding the rules or making keywords more reserved don't work (why should they). A one-token lookahead simply can't parse this. I have had some ideas about trying to play around with the precedence rules -- giving WITH TIME ZONE a higher precedence than WITH CHECK OPTION -- but I have no experience with that and I am apparently not doing it right, if that is supposed to work at all. All precedence rules do is force the parser to either shift or reduce without complaining about a conflict. i.e. it resolves the conflict by forcing a particular option. So all you would acheive with precedence rules is that you codify the solution. For example: always shift and if the user specifies WITH CHECK they get a parse error. It would be nice to be able to detect this and tell the user to parenthesise the (expr::TIME) thus solving the problem. Given that :: is not SQL-standard anyway, perhaps this is not a bad solution. Incidently, IIRC the default behaviour on conflict is a shift anyway, so that what the patch already does anyway. So we get: CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE-- OK CREATE VIEW foo AS SELECT expr :: TIME WITH CHECK OPTION -- parse error CREATE VIEW foo AS SELECT (expr :: TIME) WITH CHECK OPTION -- OK Of course, any code that decompiles into SQL will have to be careful to not produce unparseable SQL. Have a ncie day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Updatable views/with check option parsing
Martijn van Oosterhout kleptog@svana.org writes: So we get: CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE-- OK CREATE VIEW foo AS SELECT expr :: TIME WITH CHECK OPTION -- parse error CREATE VIEW foo AS SELECT (expr :: TIME) WITH CHECK OPTION -- OK I haven't really been following this conversation, but just on the off chance this is a useful idea: Would it work to make WITH just a noise word? then you would just need one token of look-ahead to recognize TIME ZONE or CHECK OPTION instead of 2. I don't know what levels clauses look like so I'm not sure if you would be able to recognize them without seeing the WITH. I'm not even sure this works even if you can for that matter. -- greg ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Updatable views/with check option parsing
Andrew Dunstan wrote: The GLR parsers require a compiler for ISO C89 or later. In addition, they use the inline keyword, which is not C89, but is C99 and is a common extension in pre-C99 compilers. It is up to the user of these parsers to handle portability issues. We already use inline, or handle its nonexistence, respectively. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Updatable views/with check option parsing
Peter Eisentraut [EMAIL PROTECTED] writes: Andrew Dunstan wrote: The GLR parsers require a compiler for ISO C89 or later. In addition, they use the inline keyword, which is not C89, but is C99 and is a common extension in pre-C99 compilers. It is up to the user of these parsers to handle portability issues. We already use inline, or handle its nonexistence, respectively. Yeah, I don't see anything in that statement that we don't assume already. The interesting question to me is how much different is GLR from garden-variety bison; in particular, what's the parser performance like? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Updatable views/with check option parsing
Tom Lane said: Peter Eisentraut [EMAIL PROTECTED] writes: Andrew Dunstan wrote: The GLR parsers require a compiler for ISO C89 or later. In addition, they use the inline keyword, which is not C89, but is C99 and is a common extension in pre-C99 compilers. It is up to the user of these parsers to handle portability issues. We already use inline, or handle its nonexistence, respectively. Yeah, I don't see anything in that statement that we don't assume already. The interesting question to me is how much different is GLR from garden-variety bison; in particular, what's the parser performance like? As I understand it, it runs one parser pretty much like the standard LALR(1) case, until it finds an ambiguity (shift/reduce or reduce/reduce) at which stage it clones the parser to take parallel paths, working in lockstep, and storing up semantic actions. When one of the clones encounters an error it goes away, and the surviving clone takes its stored semantic actions. If that's true, then probably the only significant performance hit is in cases of ambiguity, and we would only have a handful of those, each lasting for one token, so the performance hit should be very small. We'd have to test it, of course ;-) cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Updatable views/with check option parsing
Andrew Dunstan [EMAIL PROTECTED] writes: As I understand it, it runs one parser pretty much like the standard LALR(1) case, until it finds an ambiguity (shift/reduce or reduce/reduce) at which stage it clones the parser to take parallel paths, working in lockstep, and storing up semantic actions. When one of the clones encounters an error it goes away, and the surviving clone takes its stored semantic actions. If that's true, then probably the only significant performance hit is in cases of ambiguity, and we would only have a handful of those, each lasting for one token, so the performance hit should be very small. We'd have to test it, of course ;-) Yeah, I just read the same in the bison manual. The thing that's bothering me is that a GLR parser would hide that ambiguity from you, and thus changes in the grammar might cause us to incur performance hits without realizing it. The manual indicates that the performance is pretty awful whenever an ambiguity does occur. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Updatable views/with check option parsing
Tom Lane wrote: Yeah, I just read the same in the bison manual. The thing that's bothering me is that a GLR parser would hide that ambiguity from you, It doesn't really hide it. You still get the N shift/reduce conflicts warnings from bison. You just know that they are being handled. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Updatable views/with check option parsing
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: Yeah, I just read the same in the bison manual. The thing that's bothering me is that a GLR parser would hide that ambiguity from you, It doesn't really hide it. You still get the N shift/reduce conflicts warnings from bison. You just know that they are being handled. Well, that has the same problem that we've raised every other time someone has said I don't want to fix the grammar to not have any conflicts. If bison only tells you there were N conflicts, how do you know these are the same N conflicts you had yesterday? In a grammar that we hack around as much as we do with Postgres, I really don't think that's acceptable. I think that by far the most reliable solution is to put back the filter yylex function that I removed a couple months ago: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parser.c.diff?r1=1.64r2=1.65 We can use the same technique that we used for UNION JOIN, but instead join, say, WITH and TIME into one token and make the time datatype productions look for TIME WITHTIME ZONE and so on. (I propose this rather than putting the ugliness into WITH CHECK OPTION, because this way we should only need one merged token and thus only one case to check in the filter function; AFAICS we'd need three cases if we merge tokens on that end of it.) I'm not sure we can just revert the above-mentioned patch, because it had some interactions with a later patch to use %option prefix. Shouldn't be too hard to fix though. I'll put together a proposed patch. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Updatable views/with check option parsing
I wrote:
We can use the same technique that we used for UNION JOIN, but instead
join, say, WITH and TIME into one token and make the time datatype
productions look for TIME WITHTIME ZONE and so on. (I propose this
rather than putting the ugliness into WITH CHECK OPTION, because this
way we should only need one merged token and thus only one case to
check in the filter function; AFAICS we'd need three cases if we
merge tokens on that end of it.)
On investigation that turns out to have been a bad idea: if we do it
that way, it becomes necessary to promote WITH to a fully reserved word.
The counterexample is
CREATE VIEW v AS SELECT * FROM foo WITH ...
Is WITH an alias for foo (with no AS), or is it the start of a WITH
CHECK OPTION? No way to tell without lookahead.
While I don't think that making WITH a fully reserved word would cause
any great damage, I'm unwilling to do it just to save a couple of lines
of code. Accordingly, I propose the attached patch. This reinstates
the filter yylex function formerly used for UNION JOIN (in a slightly
cleaner fashion than it was previously done) and parses WITH CHECK
OPTION without any bison complaints, and with no new reserved words.
If no objections, I'll go ahead and apply this, and Peter can get on
with making the stub productions do something useful.
regards, tom lane
Index: src/backend/parser/Makefile
===
RCS file: /cvsroot/pgsql/src/backend/parser/Makefile,v
retrieving revision 1.43
diff -c -r1.43 Makefile
*** src/backend/parser/Makefile 7 Mar 2006 01:00:17 - 1.43
--- src/backend/parser/Makefile 27 May 2006 02:39:51 -
***
*** 57,63
# Force these dependencies to be known even without dependency info built:
! gram.o keywords.o: $(srcdir)/parse.h
# gram.c, parse.h, and scan.c are in the distribution tarball, so they
--- 57,63
# Force these dependencies to be known even without dependency info built:
! gram.o keywords.o parser.o: $(srcdir)/parse.h
# gram.c, parse.h, and scan.c are in the distribution tarball, so they
Index: src/backend/parser/gram.y
===
RCS file: /cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.544
diff -c -r2.544 gram.y
*** src/backend/parser/gram.y 30 Apr 2006 18:30:39 - 2.544
--- src/backend/parser/gram.y 27 May 2006 02:39:52 -
***
*** 70,75
--- 70,81
(Current) = (Rhs)[0]; \
} while (0)
+ /*
+ * The %name-prefix option below will make bison call base_yylex, but we
+ * really want it to call filtered_base_yylex (see parser.c).
+ */
+ #define base_yylex filtered_base_yylex
+
extern List *parsetree; /* final parse result is
delivered here */
static bool QueryIsRule = FALSE;
***
*** 339,344
--- 345,351
%type list constraints_set_list
%type boolean constraints_set_mode
%type str OptTableSpace OptConsTableSpace OptTableSpaceOwner
+ %type list opt_check_option
/*
***
*** 356,362
BACKWARD BEFORE BEGIN_P BETWEEN BIGINT BINARY BIT
BOOLEAN_P BOTH BY
! CACHE CALLED CASCADE CASE CAST CHAIN CHAR_P
CHARACTER CHARACTERISTICS CHECK CHECKPOINT CLASS CLOSE
CLUSTER COALESCE COLLATE COLUMN COMMENT COMMIT
COMMITTED CONNECTION CONSTRAINT CONSTRAINTS CONVERSION_P CONVERT COPY
CREATE CREATEDB
--- 363,369
BACKWARD BEFORE BEGIN_P BETWEEN BIGINT BINARY BIT
BOOLEAN_P BOTH BY
! CACHE CALLED CASCADE CASCADED CASE CAST CHAIN CHAR_P
CHARACTER CHARACTERISTICS CHECK CHECKPOINT CLASS CLOSE
CLUSTER COALESCE COLLATE COLUMN COMMENT COMMIT
COMMITTED CONNECTION CONSTRAINT CONSTRAINTS CONVERSION_P CONVERT COPY
CREATE CREATEDB
***
*** 431,436
--- 438,449
ZONE
+ /* The grammar thinks these are keywords, but they are not in the keywords.c
+ * list and so can never be entered directly. The filter in parser.c
+ * creates these tokens when required.
+ */
+ %tokenWITH_CASCADED WITH_LOCAL WITH_CHECK
+
/* Special token types, not actually keywords - see the lex file */
%token str IDENT FCONST SCONST BCONST XCONST Op
%token ival ICONST PARAM
***
*** 4618,4629
/*
*
*QUERY:
! *CREATE [ OR REPLACE ] [ TEMP ] VIEW viewname '('target-list
')' AS query
*
*/
ViewStmt: CREATE OptTemp VIEW qualified_name opt_column_list
! AS SelectStmt
{
ViewStmt *n = makeNode(ViewStmt);
Re: [HACKERS] Updatable views/with check option parsing
Ühel kenal päeval, K, 2006-05-24 kell 13:13, kirjutas Peter Eisentraut: I have spent some time figuring out how to resolve the parsing conflicts in Bernd Helmle's updatable views patch. The problem has now been reduced to specifically this situation: CREATE VIEW foo AS SELECT expr :: TIME . WITH (where expr is a_expr or b_expr and TIME could also be TIMESTAMP or TIME(x) or TIMESTAMP(x)). The continuation here could be WITH TIME ZONE (calling for a shift) or WITH CHECK OPTION (calling for a reduce). All the usual ideas about unfolding the rules or making keywords more reserved don't work (why should they). A one-token lookahead simply can't parse this. Can't we teach tokenized a new token WITH TIME ZONE ? I have had some ideas about trying to play around with the precedence rules -- giving WITH TIME ZONE a higher precedence than WITH CHECK OPTION -- but I have no experience with that and I am apparently not doing it right, if that is supposed to work at all. If we can't get that to work, it seems that we are out of options unless we want to just accept the conflicts. How should we go about this, and what should Bernd do with his patch, which, as I understand it, has been held up for quite a while simply because he is concerned about this issue? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Updatable views/with check option parsing
Hannu Krosing wrote: Can't we teach tokenized a new token WITH TIME ZONE ? No, that's three tokens, not one. We surely don't want to start making white space significant. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Updatable views/with check option parsing
Peter Eisentraut [EMAIL PROTECTED] writes: I have spent some time figuring out how to resolve the parsing conflicts in Bernd Helmle's updatable views patch. The problem has now been reduced to specifically this situation: Could we see the proposed patches for gram.y? If we can't get that to work, it seems that we are out of options unless we want to just accept the conflicts. Not acceptable, per prior discussions any time someone was too lazy to fix their grammar patch completely ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
