doc: Move list entry to proper position
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/b93c63d1972a28ffa3e16c2bc71fd60d82a57f73
Modified Files
--
doc/src/sgml/ref/psql-ref.sgml | 64 +-
1 file changed, 32 insertion
On Mon, Jun 12, 2023 at 8:20 PM Jeff Davis wrote:
> I followed the rules here for "Writing SECURITY DEFINER Functions
> Safely":
>
> https://www.postgresql.org/docs/16/sql-createfunction.html
>
> which suggests adding pg_temp at the end (otherwise it is searched
> first by default).
Interesting.
On Mon, Jun 12, 2023 at 05:39:40PM -0700, Jeff Davis wrote:
> On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote:
> > The timing was not great, but this is fixing a purported defect in an
> > older
> > v16 feature. If the MAINTAIN privilege is actually fine, we're all
> > set for
> > v16. If MAI
On Mon, 2023-06-12 at 17:50 -0700, David G. Johnston wrote:
> Only change the search_path if someone other than the table owner or
> superuser is running the command (which should only be possible via
> the new MAINTAIN privilege)?
That sounds like a reasonable compromise, but a bit messy. If we d
On Tue, 2023-06-13 at 11:24 -0400, Robert Haas wrote:
> Interesting. The issue of "what is a safe search path?" is more
> nuanced than I would prefer. :-(
As far as I can tell, search_path was designed as a convenience for
interactive queries, where a lot of these nuances make sense. But they
don'
On Mon, 2023-06-12 at 18:31 -0700, David G. Johnston wrote:
> On a related note, are we OK with someone using this privilege
> setting their own default_statistics_target?
>
> https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET
>
> My prior attempt to o
Correctly update hasSubLinks while mutating a rule action.
rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries. This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.
In p
Correctly update hasSubLinks while mutating a rule action.
rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries. This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.
In p
Correctly update hasSubLinks while mutating a rule action.
rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries. This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.
In p
Correctly update hasSubLinks while mutating a rule action.
rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries. This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.
In p
Correctly update hasSubLinks while mutating a rule action.
rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries. This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.
In p
Correctly update hasSubLinks while mutating a rule action.
rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries. This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.
In p
On Tue, Jun 13, 2023 at 12:54 PM Jeff Davis wrote:
> On Mon, 2023-06-12 at 18:31 -0700, David G. Johnston wrote:
> > On a related note, are we OK with someone using this privilege
> > setting their own default_statistics_target?
> >
> >
> https://www.postgresql.org/docs/current/runtime-config-que
Noah Misch writes:
> Best argument for shipping without $SUBJECT: we already have REFERENCES and
> TRIGGER privilege that tend to let the grantee hijack the table owner's
> account. Adding MAINTAIN to the list, while sad, is defensible. I still
> prefer to ship with $SUBJECT, not without.
What
On Tue, 2023-06-13 at 13:22 -0700, David G. Johnston wrote:
> This is the specific (first?) message I am recalling.
>
> https://www.postgresql.org/message-id/A737B7A37273E048B164557ADEF4A58B53803F5A%40ntex2010i.host.magwien.gv.at
The most objection seems to be expressed most succinctly in this
me
On Tue, Jun 13, 2023 at 1:55 PM Jeff Davis wrote:
> Perhaps the objections in that thread were because the proposal
> involved inferring the privilege to ANALYZE from other privileges,
> rather than having an explicit MAINTAIN privilege?
>
>
That is true; but it seems worth being explicit whether
Jeff Davis writes:
> The most objection seems to be expressed most succinctly in this
> message:
> https://www.postgresql.org/message-id/16134.1456767564%40sss.pgh.pa.us
> "if we allow non-owners to run ANALYZE, they'd be able to mess things
> up by setting the stats target either much lower or mu
Fix "wrong varnullingrels" for Memoize's lateral references, too.
The issue fixed in commit bfd332b3f can also bite Memoize plans,
because of the separate copies of lateral reference Vars made
by paraminfo_get_equal_hashops. Apply the same hacky fix there.
(In passing, clean up shaky grammar in
Fix make_etags breakage on certain platforms.
make_etags produced wrong format TAGS files on platforms such as Mac,
which uses non-Exuberant ctags.
Author: Masahiko Sawada
Reviewed-by: Tatsuo Ishii
Backpatch-through: 15
Discussion:
https://postgr.es/m/CAD21AoDmCqpS%2BU6b9Bc-b4OFx3tz%3DNv6O2KVkoV
Fix make_etags breakage on certain platforms.
make_etags produced wrong format TAGS files on platforms such as Mac,
which uses non-Exuberant ctags.
Author: Masahiko Sawada
Reviewed-by: Tatsuo Ishii
Backpatch-through: 15
Discussion:
https://postgr.es/m/CAD21AoDmCqpS%2BU6b9Bc-b4OFx3tz%3DNv6O2KVkoV
Fix typo in comment.
Introduced in 4d330a61bb1.
Author: Masahiko Sawada
Reviewed-by: Michael Paquier
Discussion:
https://postgr.es/m/cad21aodg8rtwjkrnjg9utp89vs8smfib2c55dvqkrcn8zr-...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4327f6c7480fea93
21 matches
Mail list logo
