Does it make sense to include the returned rows in the response? As far as I'm aware the results already exist in memory (because DBD::Pg loads the entire resultset during `execute()`). So including the resultset doesn't add memory pressure, I'd think.

[einhverfr]

          Does it make sense to include the returned rows in the response? As far as I'm aware the results already exist in memory (because DBD::Pg loads the entire resultset during `execute()`). So including the resultset doesn't add memory pressure, I'd think.
          
          (In relation to ambiguous function discovery results)

Originally posted by @ehuelsmann in #25 (comment)

Undecided discussions: How would this be formatted? Would it be one per line or a comma-separated list? Should we have some other payload for diagnostics in the exception class itself?

[ehuelsmann]

Undecided discussions: How would this be formatted? Would it be one per line or a comma-separated list? Should we have some other payload for diagnostics in the exception class itself?

Oh, I was thinking that the PGObject exception object can have a slot which holds information which identifies each matched function; e.g. the rows returned by the query. I'm not sure how to serialize that slot into the actual error message. Maybe just as a count?