Re: An XSLT example script
On 2020-04-21 21:04, Bruce Momjian wrote: On Tue, Apr 21, 2020 at 08:10:09PM +0200, Peter Eisentraut wrote: On 2020-04-14 10:03, Jürgen Purtz wrote: The example "XSLT Stylesheet for Converting SQL/XML Output to HTML" is tagged as , but it isn't a figure, it's an example script. It's not an example, it's an actual script that you are supposed to use. Uh, the text said "example", and all the other figures we had used SVG files, so it didn't see to match our other markup. The PDF output contains lists for examples, figures and tables and shows it in the wrong list. We should change the tagging. Why is it wrong to make this a figure? I thought figure was just images. Was figure really right, or something else? This is the only script we use? programlisting maybe? Maybe it's just easier to remove the wrapping in either or if that is confusing. But I request that the backpatching of this be reverted. This would renumber all the other examples and/or figures, and then it won't be clear what future bug reports will refer to. This issue isn't that drastic to make that worth it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Logical replication subscription owner
Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Alvaro Herrera writes: > > I had it in my mind that LOGIN was for regular (SQL-based) login, and > > REPLICATION was for replication login, and that they were orthogonal. > > Yeah, that's what I would've expected. Otherwise, is REPLICATION > without LOGIN useful at all? No, but it's less surprising, at least to me, for all roles that login to require having the LOGIN right. Having REPLICATION ignore that would be surprising (and a change from today). Maybe if we called it REPLICATIONLOGIN or something along those lines it would be less surprising, but it still seems pretty awkward. I view REPLICATION as allowing a specific kind of connection, but you first need to be able to login. Also- what about per-database connections? Does having REPLICATION mean you get to override the CONNECT privileges on a database, if you're connecting for the purposes of doing logical replication? I agree we could do better in these areas, but I'd argue that's mostly around improving the documentation rather than baking in implications that one privilege implies another. We certainly get people who complain about getting a permission denied error when they have UPDATE rights on a table (but not SELECT) and they include a WHERE clause in their update statement, but that doesn't mean we should assume that having UPDATE rights means you also get SELECT rights, just because UPDATE is next to useless without SELECT. Thanks, Stephen signature.asc Description: PGP signature
Re: An XSLT example script
On 23.04.20 11:40, Peter Eisentraut wrote: Maybe it's just easier to remove the wrapping in either or if that is confusing. But I request that the backpatching of this be reverted. This would renumber all the other examples and/or figures, and then it won't be clear what future bug reports will refer to. This issue isn't that drastic to make that worth it. This is a tiny patch, backpatching isn't important for me. The chapter doesn't contain any other example or figure. Therefore we shouldn't face any side effect concerning numbering. Those numbers restart in every chapter for figures, examples, and tables (there is an additional table in the huge list of tables of this chapter: "Bit String Functions" after "Bit String Operators"). -- Jürgen Purtz
Re: An XSLT example script
=?UTF-8?Q?J=c3=bcrgen_Purtz?= writes: > On 23.04.20 11:40, Peter Eisentraut wrote: >> But I request that the backpatching of this be reverted. This would >> renumber all the other examples and/or figures, and then it won't be >> clear what future bug reports will refer to. This issue isn't that >> drastic to make that worth it. > The chapter doesn't contain any other example or figure. Therefore we > shouldn't face any side effect concerning numbering. Those numbers > restart in every chapter for figures, examples, and tables (there is an > additional table in the huge list of tables of this chapter: "Bit String > Functions" after "Bit String Operators"). Yeah, Peter's point would be a good one if there were other s or s in chapter 9, but there are none today. I personally wouldn't have bothered with back-patching on the grounds of "it's unimportant" ... but now that it's done, I wouldn't revert it, on the same grounds. regards, tom lane
Re: explanation for random_page_cost is outdated
Yep. Unclear. What parameter is recommended for SSD? Lower? 3? 2? 1? Much better will be write: if you use SSD set 1. Олег > 19 марта 2020 г., в 23:56, Bruce Momjian написал(а): > > On Thu, Feb 27, 2020 at 02:48:44PM +, PG Doc comments form wrote: >> The following documentation comment has been logged on the website: >> >> Page: https://www.postgresql.org/docs/12/runtime-config-query.html >> Description: >> >> Explanation for random_page_cost is rather outdated, because it did only for >> case of mechanical hdd. But all modern database servers, which I know, made >> upon SSD. Do or not do default value for random_page_cost equal to 1 is the >> question, but, IMHO, at list in the documentation about random_page_cost >> need to add in a speculation about SSD. >> >> It's important because a business programming now is mostly web programming. >> Most database is poorly designed by web programmer, tables looked like a >> primary key and a huge json (containing all) with large gin index upon it. >> Now I am seeing a table with a GIN index 50% of the table size. The database >> is on SSD, of cause. With default random_page_cost=4 GIN index don't used >> by planner, but with random_page_cost=1 the result may be not excellent, but >> acceptable for web programmers. > > Does this sentence in the random_page_cost docs unclear or not have enough > visibility: > > > https://www.postgresql.org/docs/12/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS > >Storage that has a low random read cost relative to sequential, e.g. >solid-state drives, might also be better modeled with a lower value for >random_page_cost. > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription +
