Re: Documentation: 21.5. Default Roles
On Tue, Feb 4, 2020 at 11:31:19AM -0500, Jonathan Katz wrote: > > Using this feature to handle the rename of a file *between* major > > versions, thus leaving the changes in master, should be safe (as long > > as we add an entry to that table in pgweb). > > > > As for back branches, I think we have to say that it's too close to > > the minor release to safely have something done in pgweb before then. > > This part I agree on, but let's sync offline to see if there is > something within reason, with a preference to *not* rush if we're > worried about breaking something right before release. Folks, is it Thursday. Can we revert this and return to it when we are not rushed? Alternatively, can someone who controls all the moving parts, like redirects and Stephen's patch additions take ownership of this issue, with authority to revert the patch if things are too close? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
RETURNING does not explain evaluation context for subqueries
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/dml-returning.html Description: In the docs explaining RETURNING https://www.postgresql.org/docs/11/dml-returning.html there is no mention of the fact that a nested sub-select in the RETURNING statement executes on the table as if the INSERT/UPDATE had not happened. I suppose maybe this might be obvious if you understand how SQL works but I think it is nuanced enough that it is worth explaining here as it provides some useful features for UPSERT queries. Example: ```sql create table foo (x int primary key, y int); --=> CREATE TABLE insert into foo (x, y) values (1, 1); --=> INSERT 0 1 update foo set y = 2 where x = 1 returning (select y from foo where x = 1) as old_y; /* => * old_y * --- * 1 * (1 row) * * UPDATE 1 */ select * from foo; /* => * x | y * ---+--- * 1 | 2 * (1 row) */ ```
Re: Users/Roles do not align.
Greetings,
* Jürgen Purtz (juer...@purtz.de) wrote:
> >Based on this, I believe Section 5.9 should read:
> >`A PostgreSQL database cluster contains one or more named databases. Roles
> >are shared across the entire cluster, but no other data is shared across
> >databases. Any given client connection to the server can access only the
> >data in a single database, the one specified in the connection request.`
>
> imo the following is a more precise wording:
>
> 'A cluster contains three or more named databases ('template0', 'template1',
> 'postgres', ...). Roles, which are users or groups, see Chapter 21, - as
Roles aren't 'users or groups', they're roles, and we don't actually
have users or groups today.
> well as database names and tablespace definitions - are shared across the
> entire cluster. No other data is shared across databases or schemas. Any
> given client connection to the server can access only the data in a single
> database, the one specified in the connection request. If it has the
> necessary privileges, the connection can access all schemas within this
> database.'
There's a few things wrong about this part anyway- namely that we've got
FDWs now, and there's certainly other cluster-wide things that exist
beyond the specific items listed, so I wonder if perhaps we should just
stop trying to list everything here. The description given in 22.1
seems like it's a lot better since it talks about the hierarchy in a
general sense.
The minimalistic approach suggested initially seems like it might be the
best answer to this right now.
Thanks,
Stephen
signature.asc
Description: PGP signature
Wrong insert before trigger examples
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/ddl-partitioning.html Description: Hi, I just noticed that the example in 5.11.3.1. Point 5 contains an "before insert trigger" which will not work anymore (I think since Postgres 12). This trigger is not needed anymore and causes an error message. Best, Michael
