Hi, On 2022-12-05 20:06:55 -0500, Tom Lane wrote: > >> I wasn't trying all that hard on the error tests, because I think > >> 0003 is just throwaway code at this point. > > > I am mainly interested in having *something* test erroring out hard when > > using the "Safe" mechanism, which afaict we don't have with the patches > > as they stand. You're right that it'd be better to do that without COPY > > in the way, but it doesn't seem all that crucial. > > Hmm, either I'm confused or you're stating that backwards --- aren't > the hard-error code paths already tested by our existing tests?
What I'd like to test is a hard error, either due to an input function that wasn't converted or because it's a type of error that can't be handled "softly", but when using the "safe" interface. > > But perhaps it's even worth having such a function properly exposed: > > It's not at all rare to parse text data during ETL and quite often > > erroring out fatally is undesirable. As savepoints are undesirable > > overhead-wise, there's a lot of SQL out there that tries to do a > > pre-check about whether some text could be cast to some other data > > type. A function that'd try to cast input to a certain type without > > erroring out hard would be quite useful for that. > > Corey and Vik are already talking about a non-error CAST variant. > Maybe we should leave this in abeyance until something shows up > for that? Otherwise we'll be making a nonstandard API for what > will probably ultimately be SQL-spec functionality. I don't mind > that as regression-test infrastructure, but I'm a bit less excited > about exposing it as a user feature. Yea, I'm fine with that. I was just thinking out loud on this aspect. Greetings, Andres Freund