Re: create database with template doesn't copy ACL

[Joseph Nahmias]

On Fri, Jun 12, 2020 at 05:29:51PM -0400, Bruce Momjian wrote:
> On Fri, Jun  5, 2020 at 02:31:34PM +, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> > 
> > Page: https://www.postgresql.org/docs/11/sql-createdatabase.html
> > Description:
> > 
> > My understanding is that not copying the ACL is the (currently) expected
> > behavior when issuing CREATE DATABASE newdb WITH TEMPLATE my_tmpl;
> > It would be useful for the documentation to note this caveat.
> 
> Uh, what ACLs are not copied?

The ACL on the database itself. For example:

postgres@postgres[[local]#9655]=# CREATE DATABASE acl_template WITH IS_TEMPLATE 
= 1;
CREATE DATABASE
postgres@postgres[[local]#9655]=# REVOKE ALL ON DATABASE acl_template FROM 
PUBLIC;
REVOKE
postgres@postgres[[local]#9655]=# CREATE DATABASE acl_test WITH TEMPLATE = 
acl_template;
CREATE DATABASE
postgres@postgres[[local]#9655]=# SELECT datname, datacl FROM pg_database WHERE 
datname LIKE 'acl%';
   datname| datacl
--+-
 acl_template | {postgres=CTc/postgres}
 acl_test |
(2 rows)

Here, the ACL on the new acl_test database does NOT match the ACL on the
acl_template database upon which it is based.

Hope this helps,
--Joe

Re: Signed-ness of ints is unclear in FE-BE protocol docs

[Euler Taveira]

On Thu, 11 Jun 2020 at 15:07, Shay Rojansky  wrote:

>
> > Second, across the protocol docs, rather than using Int32 and Int64,
>> which
>> > generally look like they're signed (depending on which language you're
>> > coming from), I'd consider using UInt32/UInt64, which are unambiguous
>> with
>> > regards to signed-ness.
>>
>> Well, they are actually signed, so I'm confused why you think we should
>> change the documentation to unsigned.
>>
>
> Interesting... I'm not 100% sure, but I recently received a report that
> the WAL coordinates in XLogData (
> https://www.postgresql.org/docs/current/protocol-replication.html) are
> unsigned longs, is that a mistake? Are you saying all values in the
> protocol are always signed?
>


AFAICS, the definition is correct. Int64 means an 64-bit integer in network
byte order [1]. It does not mention signedness. All LSNs in the protocol
messages are advertised as Int64. A possible improvement is to inform that
that Int64 is a XLogRecPtr in each message block that contains LSN. It used
to be like that before the commit add6c3179a4d4fa3e62dd3e86a00f23303336bac

-  The starting point of the WAL data in this message, given in
-  XLogRecPtr format.
+  The starting point of the WAL data in this message.

but it was removed for an unknown reason.

[1] https://www.postgresql.org/docs/current/protocol-message-types.html


-- 
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services