I can imagine it's not always a good solution. reading the github issue, I think Roji is a bit dismissive here, it is a valid use case and IMHO it should just work (as in: use the type that fits the value, not throw an exception).
It's the same thing as with Oracle and decimal overflow in ODP.NET. When reading a NUMBER(10,38 ) for instance, it will bomb at runtime as it can't fit in a System.Decimal. We implemented a way to handle this, albeit using exception handling as control flow, so it has a bit of a performance hit.
See: https://www.llblgen.com/Documentation/5.4/ReferenceManuals/LLBLGenProRTF/html/3F710BF4.htm
In a partial class of DataAccessAdapter, override this method, and you can locally handle the exception when the read occurs. E.g. use a provider specific method (like suggested in the issue) to read the column. It's very specific though, so it's not a 'general handler' function, so it's meant as a last resort, for when you need to fetch these types but are unable to do so. It's not simple to determine which column failed (as that's not in the exception and we read all columns in one go with GetValues()) so you have to add specific logic in that method for that, hence the specific nature.
That said, it would be better if Npgsql simply did the right thing here and wrapped the value in the Npgsql specific type if anything. Throwing an exception is never a good thing. I'll follow up on this in the GH issue, as I think it's better to wrap it in a proper type than an exception.
