On Fri, Jul 1, 2022 at 7:58 AM Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Jul 1, 2022 at 6:01 AM Robert Haas <robertmh...@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. David J.
