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,
Laurenz
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
2eacc4bc Mon Sep 17 00:00:00 2001
From: Laurenz Albe <laurenz.a...@wien.gv.at>
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 +-
as the raw 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@postgresql.
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