On Fri, Jul 1, 2022 at 7:58 AM Peter Geoghegan <pg@bowt.ie> wrote:
On Fri, Jul 1, 2022 at 6:01 AM Robert Haas <robertmhaas@gmail.com> wrote: > What would probably help more is adding something like this to the > error message: > > HINT: column "b" could refer to any of these relations: "foo", "excluded" > > That could also help people who encounter this error in other > situations. I'm not 100% sure this is a good idea, but I feel like it > would have a much better chance of helping someone in this situation > than the proposed doc patch.
I agree with everything you've said here, though I am 100% sure that something like your proposed HINT would be a real usability win.
The "Perhaps you meant to reference the column" HINT displayed when the user misspells a column is a surprisingly popular feature. I'm aware of quite a few people singing its praises on Twitter, for example. That hardly ever happens, even with features that we think of as high impact major features. So evidently users really value these kinds of quality of life improvements.
+1 to this better approach to address the specific confusion regarding ambiguity.
Without any other changes being made I'm content with the status quo calling excluded a table a reasonable approximation that hasn't been seen to be confusing to our readers.
That said, I still think that the current wording should be tweak with respect to row vs. rows (especially if we continue to call it a table):
Current:
"The SET and WHERE clauses in ON CONFLICT DO UPDATE have access to the existing row using the table's name (or an alias), and to [rows] proposed for insertion using the special excluded table."
Change [rows] to:
"the row"
I'm undecided whether "FROM excluded" should be something that works - but I also don't think it would actually be used in any case.
