pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Subject: Re: pgsql: Fix search_path to a safe value during maintenance operations.
Date: Tue, 01 Aug 2023 15:00:16 -0700
Message-ID: <719aefb79d03f6b871aa05812d4547a08691c25f.camel@j-davis.com> (raw)
In-Reply-To: <CA+Tgmobd=eFRGWHhfG4mG2cA+dsVuA4jpBvD8N1NS=Vc9eHFQg@mail.gmail.com>
References: <E1q7j7Y-000z1H-Hr@gemulon.postgresql.org>
	<89a415b86d5421941e4281ba5bf6288934078624.camel@j-davis.com>
	<d20864b929ff769a0ebf772359719f05bb6982cd.camel@j-davis.com>
	<573014.1686375211@sss.pgh.pa.us>
	<20230612170510.GA201972@gust.leadboat.com>
	<f53df2dbe11bb42764bcdd003a54aa29c9bb6137.camel@j-davis.com>
	<20230613182920.GA259321@gust.leadboat.com>
	<1799839.1686687804@sss.pgh.pa.us>
	<4df537f5a0d8c0ceac3eec3809d1144880b8e76d.camel@j-davis.com>
	<CA+TgmoYtJU0KknWr11W--wK=4eJtdHOgupyT=beZVPC8P=o+YA@mail.gmail.com>
	<578fb4be80247570e6a05924908765a0b345971e.camel@j-davis.com>
	<CA+TgmoZVCHERUkXhAMT2Er-sKBc5C6_iX+TpxxivBevDHzq2TQ@mail.gmail.com>
	<43bbc9f7318057f51552d5986830908cb018dadf.camel@j-davis.com>
	<1659699.1688086436@sss.pgh.pa.us>
	<fff566293c9165c69bb4c555da1ac02c63660664.camel@j-davis.com>
	<CA+Tgmoa5mksH1rAggYYwm0fJAO8TCnLG_oRE=su06XfqU+KTLA@mail.gmail.com>
	<fde3f0e0991d8d68c5abcf3fb54ad106e73da4e7.camel@j-davis.com>
	<CA+Tgmobd=eFRGWHhfG4mG2cA+dsVuA4jpBvD8N1NS=Vc9eHFQg@mail.gmail.com>

On Tue, 2023-08-01 at 13:41 -0400, Robert Haas wrote:
> In functions and procedures, except for the new
> BEGIN ATOMIC stuff, we just store the statements as a string and they
> get parsed at execution time.

...

> I think that a lot of people would like it if we moved more in the
> direction of parsing statements at object definition time.

Do you mean that we'd introduce some BEGIN ATOMIC version of plpgsql
(and other trusted languages)?

>  However, there are some
> fairly significant problems with that idea.

To satisfy intended use cases of things like default expressions, CHECK
constraints, index expressions, etc., there is no need to call
functions that would be subject to the problems you list.

One problem is that functions are too general a concept -- we have no
idea whether the user is trying to do something simple or trying to do
something "interesting".

> Now, if we don't go in the direction of resolving everything at parse
> time,

It would be useful to pursue this approach, but I don't think it will
be enough. We still need to solve our search_path problems.

>  then I think capturing search_path is probably the next best
> thing,

+0.5.

>  To be honest, I think it's
> a
> bit of a kludge, and dropping a kludge on top of our entire user base
> and maybe also breaking a lot of things is not particularly where I
> want to be. I just don't have an idea I like better at the moment.

We will also be fixing things for a lot of users who just haven't run
into a problem *yet* (or perhaps did, and just don't know it).

Regards,
	Jeff Davis








view thread (59+ messages)  latest in thread

Message-ID: <719aefb79d03f6b871aa05812d4547a08691c25f.camel@j-davis.com>
Permalink:  ../719aefb79d03f6b871aa05812d4547a08691c25f.camel@j-davis.com/
Also on:    postgresql.org/message-id/719aefb79d03f6b871aa05812d4547a08691c25f.camel@j-davis.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: pgsql@j-davis.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, noah@leadboat.com, pgsql-hackers@postgresql.org, nathandbossart@gmail.com
  Subject: Re: pgsql: Fix search_path to a safe value during maintenance operations.
  In-Reply-To: <719aefb79d03f6b871aa05812d4547a08691c25f.camel@j-davis.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox