Re: COPY (INSERT/UPDATE/DELETE .. RETURNING ..)
От | Marko Tiikkaja |
---|---|
Тема | Re: COPY (INSERT/UPDATE/DELETE .. RETURNING ..) |
Дата | |
Msg-id | 564DBEE8.5090400@joh.to обсуждение исходный текст |
Ответ на | Re: COPY (INSERT/UPDATE/DELETE .. RETURNING ..) (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: COPY (INSERT/UPDATE/DELETE .. RETURNING ..)
|
Список | 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
В списке pgsql-hackers по дате отправления: