Re: Link t the souce code
On 21.07.21 01:45, Alvaro Herrera wrote:
-gunzip postgresql-&version;.tar.gz
-tar xf postgresql-&version;.tar
+tar xfa postgresql-&version;.tar.gz
The "a" option only applies when creating a tar archive ("c" command).
So adding it here does nothing.
Re: Link t the souce code
On 2021-Jul-21, Peter Eisentraut wrote:
> On 21.07.21 01:45, Alvaro Herrera wrote:
> >
> > -gunzip postgresql-&version;.tar.gz
> > -tar xf postgresql-&version;.tar
> > +tar xfa postgresql-&version;.tar.gz
> >
>
> The "a" option only applies when creating a tar archive ("c" command). So
> adding it here does nothing.
Oh, so the current `tar x` knows to uncompress the file without any
additional options? I've been pointlessly adding 'z', 'j', 'a' for years ...
That means we can remove the `gunzip` line and replace it with nothing.
WFM ...
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"But static content is just dynamic content that isn't moving!"
http://smylers.hates-software.com/2007/08/15/fe244d0c.html
Re: Link t the souce code
Alvaro Herrera writes: > Oh, so the current `tar x` knows to uncompress the file without any > additional options? I've been pointlessly adding 'z', 'j', 'a' for years ... I wonder whether that's GNU-tar-specific. But we have GNU-isms elsewhere, eg we removed references to "gmake" years ago. If someone is dealing with a tar program that needs the extra option, they probably know what to do. > That means we can remove the `gunzip` line and replace it with nothing. > WFM ... WFM too. The other thing I wonder about is whether the example shouldn't be assuming that you chose the .bz2 file instead of the .gz one. regards, tom lane
Re: Link t the souce code
On 2021-Jul-21, Tom Lane wrote: > Alvaro Herrera writes: > > That means we can remove the `gunzip` line and replace it with nothing. > > WFM ... > > WFM too. The other thing I wonder about is whether the example shouldn't > be assuming that you chose the .bz2 file instead of the .gz one. Seems reasonable -- pushed with that last change. Thanks! -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
Re: Link t the souce code
On 21.07.21 19:21, Alvaro Herrera wrote:
On 2021-Jul-21, Peter Eisentraut wrote:
On 21.07.21 01:45, Alvaro Herrera wrote:
-gunzip postgresql-&version;.tar.gz
-tar xf postgresql-&version;.tar
+tar xfa postgresql-&version;.tar.gz
The "a" option only applies when creating a tar archive ("c" command). So
adding it here does nothing.
Oh, so the current `tar x` knows to uncompress the file without any
additional options? I've been pointlessly adding 'z', 'j', 'a' for years ...
That means we can remove the `gunzip` line and replace it with nothing.
Unless you want to assume GNU tar, the gunzip is still necessary.
Re: Link t the souce code
Alvaro Herrera writes: > Seems reasonable -- pushed with that last change. Hm ... actually, now that I read the committed patch, I realize that it's effectively recommending that people build their installations from the latest commit on master. That might be what aspiring PG hackers want to do, but it's quite unlikely that Joe DBA wants to. I think if we're going to recommend pulling the git repo as the way to get the sources, we at least ought to recommend a "git checkout REL_n_STABLE" step, and point out that this gives you branch tip not a released-and-QAed version. On the whole though, I'm having qualms about recommending this in this particular spot, rather than back in Appendix I. Seems like the wrong audience is going to be reading this chapter. regards, tom lane
Re: Link t the souce code
On 2021-Jul-21, Tom Lane wrote: > Hm ... actually, now that I read the committed patch, I realize that > it's effectively recommending that people build their installations > from the latest commit on master. That might be what aspiring PG > hackers want to do, but it's quite unlikely that Joe DBA wants to. > I think if we're going to recommend pulling the git repo as the > way to get the sources, we at least ought to recommend a > "git checkout REL_n_STABLE" step, and point out that this gives > you branch tip not a released-and-QAed version. On the whole though, > I'm having qualms about recommending this in this particular spot, > rather than back in Appendix I. Seems like the wrong audience is > going to be reading this chapter. Well, we can remove that first paragraph from there and just refer the reader to the appendix ... something like this, perhaps. The appendix already has instructions on cloning the repo. It doesn't say anything about branches though, but I'm not sure we want our docs to become a tutorial on Git. We already link to git-scm.com though that's not great; it doesn't explain our branch structure for example. We could do better. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index fddd7d3905..16856f7736 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -354,24 +354,8 @@ su - postgres Getting the Source - The version control repository for PostgreSQL - can be obtained from - https://git.postgresql.org/gitweb/?p=postgresql.git;a=summary";>; - this is the recommended way to obtain the - PostgreSQL source code. - You can obtain a clone of the repository by running - -git clone https://git.postgresql.org/git/postgresql.git - - This will create a directory postgresql under the current - directory with the PostgreSQL sources. - Change into that directory for the rest of the installation procedure. - See for further information. - - - - Alternatively, source code for the released versions can be obtained - from the download section of our website: + The PostgreSQL source code for released versions + can be obtained from the download section of our website: https://www.postgresql.org/ftp/source/";>. Download then postgresql-version.tar.gz @@ -385,6 +369,10 @@ su - postgres the current directory with the PostgreSQL sources. Change into that directory for the rest of the installation procedure. + + + Alternatively, you can use the Git version control system; see +for more information.
Re: Link t the souce code
Peter Eisentraut writes: > On 21.07.21 19:21, Alvaro Herrera wrote: >> Oh, so the current `tar x` knows to uncompress the file without any >> additional options? I've been pointlessly adding 'z', 'j', 'a' for years ... >> That means we can remove the `gunzip` line and replace it with nothing. > Unless you want to assume GNU tar, the gunzip is still necessary. That seems overly conservative. On my Mac, Apple has kindly provided $ tar --version bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6 and in case the mentioned libraries aren't enough clue, it does indeed seem to work like GNU tar for this purpose: $ tar tf postgresql-10.16.tar.bz2 | head -5 postgresql-10.16/ postgresql-10.16/.dir-locals.el postgresql-10.16/contrib/ postgresql-10.16/contrib/tcn/ postgresql-10.16/contrib/tcn/tcn.control A nearby FreeBSD box provides similar results. So the proposed instructions probably work fine on most *BSD machines. I also looked on Solaris 11, and here's what "man tar" has to say there: j c mode only. Compress the resulting archive with bzip2. In extract or list modes, this option is ignored. The implementation recog- nizes bzip2 compression type automatically when reading archives. Upgrade/replace first decompresses and then applies the same mecha- nism to compress the archive automatically. I think this is another case of a GNUism that's become close enough to universal that we don't need to be pedantic about it. regards, tom lane
Re: Link t the souce code
Alvaro Herrera writes: > On 2021-Jul-21, Tom Lane wrote: >> I'm having qualms about recommending this in this particular spot, >> rather than back in Appendix I. Seems like the wrong audience is >> going to be reading this chapter. > Well, we can remove that first paragraph from there and just refer the > reader to the appendix ... something like this, perhaps. +1, though I think you're short a or so. > The appendix already has instructions on cloning the repo. It doesn't > say anything about branches though, but I'm not sure we want our docs to > become a tutorial on Git. We already link to git-scm.com though that's > not great; it doesn't explain our branch structure for example. We > could do better. Agreed that we're not here to teach people how to use git. But it'd be worth explaining our branch naming conventions in that appendix. It'd be sufficient I guess to mention "master" and "REL_n_STABLE"; by the time v15 sees the light of day, all the pre-v10 branches will be EOL. (Maybe also explain the REL_m_n release tags?) regards, tom lane
Re: Exponentiation example not clear
PG Doc comments form writes: > Quoting the docs: > Exponentiation (unlike typical mathematical practice, multiple uses of ^ > will associate left to right) > 2 ^ 3 → 8 > 2 ^ 3 ^ 3 → 512 > You could probably add > 2 ^ (3 ^ 3) → 134217728 # 2 ^27 Seems reasonable, done at https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7fa1e1ef741964eeb50f33d7c72622658bb7e5f4 regards, tom lane
