l as (crucially) which certificates failed to
> verify,
> and at what depth, so the admin can zoom in straight onto the problem without
> any guessing.
+1 for the idea.
I have been in this situation before, and any information that helps to
clarify what the problem is would be a great he
Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > Robert Haas wrote:
> > > One trick that some system use is avoid replanning as much as we do
> > > by, for example, saving plans in a shared cache and reusing them even
> > > in other
Tom Lane wrote:
>> But types also have the USAGE privilege for PUBLIC by default:
>
> Yup, that's an oversight.
>
>> Hence I propose the attached documentation patch.
>
> Pushed, with a bit of additional wordsmithing.
Thanks for taking the time.
Yours,
La
ws
too large if the application does not use prepared statements
but dynamic SQL with varying constants.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
213e1e91cd0c45fcca8df492f1017f2eacc4bc Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 10 Oct 2017 09:21:36 +0200
Subject: [PATCH] Fix documentation of default privileges for types
Document that PUBLIC has USAGE privileges on newly created types.
---
doc/src/sgml/ref/grant.sgml | 2 +-
aw list.
> The list is sorted using COLLATE "en-x-icu".
It would be awesome if the list could be sorted by last name,
as name lists traditionally are, but maybe that's too much to ask.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
There has been a previous discussion about this topic, including an attempted
fix by Amit Kapila:
http://www.postgresql.org/message-id/flat/CAA4eK1L=tHmmHDK_KW_ja1_dusJxJF+SGQHi=aps4mdnpk7...@mail.gmail.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
