Re: [HACKERS] Incautious handling of overlength identifiers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Incautious handling of overlength identifiers
Date
Msg-id 7096.1482773527@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Incautious handling of overlength identifiers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Incautious handling of overlength identifiers
List pgsql-hackers
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.

Since the low-level functions need to support both use cases, asking
them to handle truncation is wrong, just as much as it would be to
ask them to do downcasing.

If we take these SQL functions as being meant for use with inputs
coming from catalogs, then they don't need to do truncation for
user-friendliness purposes; it's perfectly fine to treat overlength
inputs as "name not found" cases.  So that says we could just remove
that Assert and decide we're done.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: session server side variables