Tom Lane wrote:
> I wrote:
> > Another idea worth considering is to just make the low-level functions
> > do truncation ...
>
> After further thought, there's a bigger-picture issue here, which
> is whether the inputs to the SQL functions in question are intended to
> be raw user input --- in which case, not only would truncation be
> an appropriate service, but probably so would downcasing --- or whether
> they are more likely to be coming from a catalog scan, in which case
> you don't want any of that stuff. Nobody's going to be happy if we
> start making them add quote_ident() around references to name columns.
> I think the privilege-inquiry functions are almost certainly mostly
> used in the latter style; there might be more room for debate about,
> say, pg_get_serial_sequence.
I expect that uses of pg_get_object_address() (one of the affected
interfaces) would mostly be through an event trigger or a similar
internal mechanism, that hopefully should appropriately quote names and
not produce anything overlength. At least, pg_identify_object() (which
is what I mostly had in mind) complies. I think removing the assert is
a good enough solution, myself.
I also admit it didn't occur to me to test the function(s) against
overlength input when developing it. I wouldn't object to adding code
to deal with overlength identifies, but I'm not really sure I would
choose truncation over reporting an error. But whatever it'd be, it'd
be at that level, not at the lower (hash function) level.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services