On Tue, May 11, 2021 at 03:51:39PM -0400, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: > > On 5/11/21 1:30 PM, Bruce Momjian wrote: > >> It just feels like this change makes the function's behavior less > >> consistent. > > > See Tom's commit message here: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3d0f68dd30612 > > > In particular: > > > "The variants of these functions that take > > numeric inputs (OIDs or column numbers) are > > supposed to return NULL rather than failing > > on bad input; this rule reduces problems with > > snapshot skew when queries apply the functions > > to all rows of a catalog." > > Yeah, the null-return-for-bad-numeric-input behavior is important. > Perhaps a case could be made for returning null for bad text > input too, but I don't recall that anybody has asked for that. > > A case could also be made that changing the behavior on the text > side would break applications that expect the current behavior. > So I'm disinclined to make a wholesale change there, without more > evidence that it's a good idea.
OK, as long as we thought about this, I am fine. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.