From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY (INSERT/UPDATE/DELETE .. RETURNING ..) |
Date: | 2015-11-19 12:22:00 |
Message-ID: | 564DBEE8.5090400@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/19/15 1:17 PM, Michael Paquier wrote:
> On Thu, Nov 19, 2015 at 11:04 AM, Marko Tiikkaja wrote:
>> Further, if someone's going to add new stuff to PreparableStmt, she should
>> probably think about whether it would make sense to add it to COPY and CTEs
>> from day one, too, and in that case not splitting them up is actually a win.
>
> Personally, I would take it on the safe side and actually update it.
> If someone were to add a new node type in PreparableStmt I am pretty
> sure that we are going to forget to update the COPY part, leading us
> to unwelcome bugs. And that would not be cool.
They'd have to get past this:
+ if (query->commandType != CMD_SELECT &&
+ query->returningList == NIL)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("COPY query must have a RETURNING
clause")));
+ }
Of course, something might break if we added a new statement type which
supported RETURNING, but I'm really not worried about that. I'm not
dead set against adding some Assert(IsA()) calls here, but I don't see
the point.
.m
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-11-19 13:11:22 | Re: warning: HS_KEY redefined (9.5 beta2) |
Previous Message | Thom Brown | 2015-11-19 12:19:23 | Re: Error with index on unlogged table |