From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CREATE POLICY and RETURNING |
Date: | 2014-10-17 11:54:52 |
Message-ID: | 20141017115452.GV28859@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* David G Johnston (david(dot)g(dot)johnston(at)gmail(dot)com) wrote:
> How about returning a placeholder row but with all the values replaced with
> NULL?
I don't think that would be a good approach.. A user actually looking
at those rows would be highly confused.
> In the absence of returning does the delete count show the total number of
> rows deleted or only the number of rows deleted that the user would be aware
> of if they issued a select with the same criteria? Whatever the answer the
> number of rows returned with returning should match the row count normally
> noted.
Today, everything matches up, yes. Having rows which are deleted but
which don't show up in RETURNING could certainly surprise people and
applications, which is why I tend to favor the 'all-or-error' approach
that others have also suggested. Adding that wouldn't be difficult,
though we'd need to decide which should be the default.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2014-10-17 12:23:43 | Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves) |
Previous Message | Amit Kapila | 2014-10-17 11:52:18 | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |