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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
