here is a new patch containing all changes you (Tom) suggested to make. I
still use my "pavlo (pbpbit.org)" for me to locate my code; feel free to
illiminate them before integrating :-)
> This would break
> INSERT INTO foo(textcolumn) VALUES ('@default')
> which I find hardly acceptable.
> The only way to do it without breaking valid data entries is to
> introduce a new parse node type to represent a DEFAULT placeholder.
Now there is a newly declared parse node type "Default" - the corresponding
structure has no data. The "@default" hack is now illiminated - I'm the
happiest about it
> I also wonder what's going to happen if I write DEFAULT in a SELECT's
> targetlist, which is possible given where you made the grammar change.
The grammer now contains two new rules: "insert_target_list" and
"insert_target_el", the SELECT and INSERT don't use the same targetlist
anymore, but the "insert_target_el" completely inherits "target_el" to avoid
multiple declarations and it just provides the new DEFAULT-rule.
I hope, this patch is ok - to me, it looks correct now
Description: application/octet-stream (6.2 KB)
In response to
- Re: patch: INSERT INTO t VALUES (a, b, ..., DEFAULT, ...) at 2002-02-23 01:48:36 from Bruce Momjian
- Re: patch: INSERT INTO t VALUES (a, b, ..., DEFAULT, ...) at 2002-03-08 00:57:56 from Bruce Momjian
- Re: patch: INSERT INTO t VALUES (a, b, ..., DEFAULT, ...) at 2002-03-08 01:01:44 from Bruce Momjian
pgsql-hackers by date
|Next:||From: Pavlo Baron||Date: 2001-12-27 20:58:06|
|Subject: TODO question|
|Previous:||From: Scott Royston||Date: 2001-12-27 20:37:14|
|Subject: Implicit cast of literal in SQL statements|