Re: Incautious handling of overlength identifiers
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>, Joe Conway <mail@joeconway.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2016-12-26T18:36:47Z
Lists: pgsql-hackers
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
Commits
-
Remove triggerable Assert in hashname().
- 607d0cd14872 9.2.20 landed
- a6d5e47e68d1 9.3.16 landed
- 56d58fa0415c 9.4.11 landed
- 987c4b401f46 9.5.6 landed
- 462ab6c8b2b8 9.6.2 landed
- 54386f357825 10.0 landed