Re: patch: INSERT INTO t VALUES (a, b, ..., DEFAULT, ...)

> "Pavlo Baron" <pb(at)pbit(dot)org> writes:
> > 3. gram.y - here I added a rule for the DEFAULT-element in the
target_list
> > used for the INSERT-statement. It now replaces DEFAULT by an anti-thing
like
> > "@default" because I couldn't find out were it fails if I leave DEFAULT
> > unchainged. If smb. knows a way to do it I'll drop this @default
>

Tom Lane writes:
> 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.

I know what you mean and I hope to know where to do it. I thought, there
could be some similar cases handled a similar way. I'll try to implement
providing a new parse node type to represent a DEFAULT placeholder.

Tom Lane writes:
>
> 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.

I also thought about it, but maybe I tested a wrong statement. Could you
give me an example on what you mean would possibly appear funny? a
select-statement...
Maybe I don't understand what the targetlist means in the case of the select
statement. I tried smth. like "select f1, f2 from tab1;". I think, "f1, f2"
is a targetlist and if I try to use DEFAULT in the list, a parser error is
generated as it was before I put my changes.
I could specify a new targetlist branch used only in the case of the INSERT
statement, and that's what I had before I minimized my code to that what you
see now. I think, I see a way to declare a rule only used with the INSERT
statement, but I couldn't find any problem caused by using default in the
targetlist of the SELECT stmt. What should we do?

rgds
Pavlo Baron