Re: Facility for detecting insecure object naming

From: Nico Williams <nico(at)cryptonector(dot)com>
To: "Nasby, Jim" <nasbyj(at)amazon(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Facility for detecting insecure object naming
Date: 2018-08-15 15:40:55
Message-ID: 20180815154054.GA29462@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 14, 2018 at 11:50:24PM +0000, Nasby, Jim wrote:
> On Aug 14, 2018, at 4:01 PM, Nico Williams <nico(at)cryptonector(dot)com> wrote:
> >
> > On Tue, Aug 14, 2018 at 03:00:55PM +0000, Robert Haas wrote:
> >> The more I think about it, the more I think having a way to set a
> >> lexically-scoped search path is probably the answer. [...]
> >
> > Yes please!
> >
> > This is what I want. Evaluate the search_path at function definition
> > time, and record code with fully-qualified symbols in the catalog.
>
> Unfortunately, that falls apart for relocatable extensions.

It would only require recomputing the bindings at relocation time. IMO
PG should not allow extension relocation after installation either, but
sadly it does.

Nico
--

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-08-15 15:41:46 Re: C99 compliance for src/port/snprintf.c
Previous Message Robert Haas 2018-08-15 15:05:06 Re: Facility for detecting insecure object naming