Binary format for array in COPY-command
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.5/static/datatype-bit.html Description: Hi, I could not find description of arrays for 9.6 Postgres: https://www.postgresql.org/docs/9.6/static/sql-copy.html Array fields have different format than all other data. They have it's own header - and i want to know field description. I added hardcode support of smallint[] into this module: https://github.com/altaurog/pgcopy And need full description to create full support of arrays.
Re: generate.consistent.ids
On 12/1/17 13:39, Peter Eisentraut wrote: > I found that the setting > > > > also enables the XSL stylesheets to produce anchors that are consistent > across builds. I would have expected that to increase the build time, > but in my testing the penalty is barely noticeable. So I would like to > make this change in PG11 and also PG10. Patch attached. committed to master and PG10 -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Binary format for array in COPY-command
vla...@gmail.com writes: > I could not find description of arrays for 9.6 Postgres: > https://www.postgresql.org/docs/9.6/static/sql-copy.html I do not think it's explicitly documented anyplace (neither is the binary format for anything else, really). But you can work it out easily enough by looking at array_send and array_recv: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob_plain;f=src/backend/utils/adt/arrayfuncs.c;hb=HEAD regards, tom lane
Re: [DOCS] Building 10.0 PDFs - fop config
On 10/5/17 09:33, Dave Page wrote: > Whilst building the 10.0 PDF docs for the website, I found I needed to > modify the fop configuration on the Debian Jessie build host. What > worked for me was: > > pgsql@:~$ cat ~/.foprc > > JAVA_ARGS='-Xms1024M -Xmx2048M' I have committed this with -Xmx1500M, which seemed to give enough wiggle room. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
documentation for SQL "COPY" says "FORMAT"
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.0/static/sql-copy.html Description: the documentation for the copy command (since version 9.0) says to use the keyword "FORMAT" , this keyword should be omitted (eg: say "CSV" instead of "FORMAT CSV") . It also says the default is "text" but specifying "text" is a syntax error.
Re: documentation for SQL "COPY" says "FORMAT"
On Tue, Dec 5, 2017 at 5:01 PM, wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.0/static/sql-copy.html > Description: > > the documentation for the copy command (since version 9.0) says to use the > keyword "FORMAT" , this keyword should be omitted (eg: say > "CSV" instead of > "FORMAT CSV") . It also says the default is "text" but > specifying "text" is > a syntax error. > I'm pretty sure the docs are correct. You should provide the exact commands you think should work and the error message you receive when you execute said commands. David J.
Re: documentation for SQL "COPY" says "FORMAT"
"David G. Johnston" writes: > On Tue, Dec 5, 2017 at 5:01 PM, wrote: >> the documentation for the copy command (since version 9.0) says to use the >> keyword "FORMAT" , this keyword should be omitted > I'm pretty sure the docs are correct. You should provide the exact > commands you think should work and the error message you receive when you > execute said commands. I think probably the OP is confusing the current COPY syntax with the obsolete form documented at the bottom of the COPY page. regards, tom lane
Re: Flex is not a GNU package
On 11/24/17 14:03, Pavan Maddamsetti wrote: > The comment form mangled my diff. > > --- > > diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml > index a922819..141494c 100644 > --- a/doc/src/sgml/installation.sgml > +++ b/doc/src/sgml/installation.sgml > @@ -289,7 +289,7 @@ su - postgres > yacc > > > - GNU Flex and > Bison > + Flex and Bison >are needed to build from a Git checkout, or if you changed the actual >scanner and parser definition files. If you need them, be sure >to get Flex 2.5.31 or later and > committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: MacPorts xsltproc is very slow?
On 11/26/17 17:03, Thomas Munro wrote: > So one solution is simply to uninstall the docbook-xsl package. That > gets me back to fast documentation builds! Incidentally, uninstalling > the docbooks-xsl package also works for FreeBSD which currently ships > a too-old DocBook version. This is actually documented: https://www.postgresql.org/docs/devel/static/docguide-toolsets.html > I believed until now that it couldn't > build the PostgreSQL docs, so I'm very happy to discover that it can, > but (1) it needs the network (2) it's using HTTP instead of HTTPS so > Alice could mess with Bob's documentation. Good point. I have filed a bug about this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Replication parameters in recovery.conf
On 12/1/17 06:12, Aleksandr Parfenov wrote: > Reading a documentation regarding recovery.conf file I found that the > reason to store 'stand-by mode' configuration inside that file is not > clear. > > IMHO, a little note in description of recovery.conf will clearify > the situation. Something like "a stand-by is submode of recover mode" > and that the file used during replication will help. Same as in > recovery.conf.sample file will be fine too. > > What the community thinks about it? The reasons for this are basically all historical and we are trying to get rid of it (by moving these settings to postgresql.conf, mostly). So I don't think we need to spend a lot of time rationalizing this at this point. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Replication parameters in recovery.conf
On Wed, Dec 6, 2017 at 11:19 AM, Peter Eisentraut wrote: > The reasons for this are basically all historical and we are trying to > get rid of it (by moving these settings to postgresql.conf, mostly). So > I don't think we need to spend a lot of time rationalizing this at this > point. Yeah, there are as well parameters that could get removed on the way, like hot_standby for example. Most deployments don't use it to off these days, and in Postgres 10 this moves makes even more sense as wal_level = replica maps to both "archive" and "hot_standby", but means the latter. -- Michael
