Re: Incautious handling of overlength identifiers

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Incautious handling of overlength identifiers
Date: 2016-12-26 18:36:47
Message-ID: 20161226183647.hjlzi2vqyqvyevsa@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-12-26 18:37:30 Re: proposal: session server side variables
Previous Message Pavel Stehule 2016-12-26 18:13:58 Re: proposal: session server side variables