[DOCS] Improve pg_restore docs
Hi, From a quick discussion on hackers (http://archives.postgresql.org/pgsql-hackers/2009-06/msg01434.php), it appears the documentation can improve for pg_restore. I've prepared some quick diff output from pgsql/doc/src/sgml/ref/pg_restore.sgml for some changes that I think would help. Note that I'm not entirely sure about the default namespace from default_path .. please verify this before accepting. Edit as necessary. 291c291,292 < specific table. --- > specific table. The default is taken from the > default_path variable. 379c380,382 < Restore definition and/or data of named table only. --- > Restore definition and/or data of named table only. This can be > combined with the -n option to restore a table > from a specific schema. Thanks, -Mike -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Improve pg_restore docs
Greg Smith wrote: The standard way to submit patches here is to attach a file with a full context diff (diff -c) to the message, rather than putting it inline or including just the changes. The idea is to make it easy for the committers to grab your patch and apply it. Part of my hesitation in attaching the patch is that I'm on a Windows computer (be aware of CRLF line endings in the attached). Apply to pgsql/doc/src/sgml/ref/pg_restore.sgml -Mike 291c291,292 < specific table. --- > specific table. The default is taken from the > default_path variable. 379c380,382 < Restore definition and/or data of named table only. --- > Restore definition and/or data of named table only. This can be > combined with the -n option to restore a table > from a specific schema. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On 22 June 2010 18:49, Tom Lane wrote: > Thom Brown writes: >> Is that the right behaviour though? Shouldn't the signed value reach >> the cast step rather than the absolute value? Or maybe Postgres could >> implicitly accept -12345::integer to be (-12345)::integer. Is there a >> blocking reason as to why it must work this way? > > Yes. There is no reason to assume that - means the same thing for every > datatype. In general, :: should (and does) bind tighter than *every* > operator, to ensure that the appropriately typed operator is applied. > Sorry for adding to the non-DOC drift, but why is - assumed to be a unary operator on an unsigned integer, rather than parsed as part of an integer? Integers have digits with an optional - or + prefix (not unary operators). E.g., ([+\-]?[0-9]+) -Mike -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Rename install-win32?
Hi, While files are being renamed in the main repo, is it possible to rename install-win32.sgml ? "win32" implies a 32-bit windows architecture, which is dated and misleading. Could I suggest: git mv doc/src/sgml/install-win32.sgml doc/src/sgml/install-windows.sgml and fix chapter_id references from "install-win32" to "install-windows"? Are there consequences for renaming this file/chapter_id? -Mike -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Latest release date formatting on http://www.postgresql.org/
See "latest releases" in the upper-left corner on http://www.postgresql.org/ 9.0.1 · 2010-10-04 · Notes 8.4.5 · 2010-10-04 · Notes 8.3.12 · 2010-10-04 · Notes 8.2.18 · 2010-04-10 · Notes 8.1.22 · 2010-04-10 · Notes The dates should follow a consistent Y-M-D formatting: 9.0.1 · 2010-10-04 · Notes 8.4.5 · 2010-10-04 · Notes 8.3.12 · 2010-10-04 · Notes 8.2.18 · 2010-10-04 · Notes 8.1.22 · 2010-10-04 · Notes -Mike -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] pg_dump -t '"Table"' for cmd.exe
I'm not sure if this is worth documenting, but pg_dumping mixed-case tables with the '-t table' option appears to not be accurately documented for cmd.exe. Here are my four attempts, with only the last as success: Intuitive (supplying "My Table" like "My Database"), but not correct: C:\>"C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe" -U postgres -t "My Table" "My Database" pg_dump: No matching tables were found As documented in last example at http://www.postgresql.org/docs/9.1/static/app-pgdump.html C:\>"C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe" -U postgres -t '"My Table"' "My Database" pg_dump: No matching tables were found Escaping quotes, but using single quotes: C:\>"C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe" -U postgres -t '\"My Table\"' "My Database" pg_dump: too many command-line arguments (first is "My Database") Escaping quotes, but using double quotes: C:\>"C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe" -U postgres -t "\"My Table\"" "My Database" works! -Mike
Re: [DOCS] ST_AsLatLonText bug
On 18 January 2017 at 09:57, wrote:
> select
> (ST_AsLatLonText('POINT ('||(-76.6)||' '||(35.1)||')', 'DD°MM''SS.SSS&C'))
> dms
>
> returns unexpected 60 seconds
> 35° 6'0.000&N 76°35'60.000&W
This is not a PostgreSQL bug. PostGIS bugs go to https://trac.osgeo.org/postgis
See https://trac.osgeo.org/postgis/ticket/3688 for this issue.
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Online docs links for 10.0 vs 10
I think the documentation links for version 10 need attention. The series of documentation text and links for the current releases are 9.5, 9.6: ... https://www.postgresql.org/docs/9.5/static/ https://www.postgresql.org/docs/9.6/static/ so I would have expected the new batch of releases[1] to similarly list only major versions 10, 11: https://www.postgresql.org/docs/10/static/ https://www.postgresql.org/docs/11/static/ ... however, the current link to the beta includes the minor release digit 10.0: https://www.postgresql.org/docs/10.0/static/ (current docs don't link to minor versions like 9.6.3, so this is counter-intuitive to me). This comment similarly applies to the text of the links at https://www.postgresql.org/docs and the list of versions at the top of the online docs template where you see "This page in other versions". I was expecting to see 10 and not 10.0 in these places. Cheers, -Mike [1] http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Reg Date/Time function
On 1 August 2017 at 12:30, wrote: > Hi, > I am going through PostgreSQL, for the first day. And it was great till > now. > One quick question/doubt regarding the function > "justify_days(interval)" > > select justify_days(interval '365 days'); > > this statement returns 1 year 5 days, whereas I feel it should be just 1 > year. > > Please correct me if I am wrong.. Thanks for all your time. It seems you are trying to convert a time interval type to days. The most reliable way to get this is to extract the epoch, which is in number of seconds, then convert this to days (divide by 60 * 60 * 24). SELECT x, extract(epoch from x)/86400 AS days FROM ( SELECT '1 year'::interval AS x UNION ALL SELECT '365 days' ) AS sub; x | days --+ 1 year | 365.25 365 days |365 (2 rows) A typical "year" indeed has 365.25 days, when you consider leap years typically every 4th. As noted previously, justify_days(interval) has a special use for 360-day calendars[1]. [1] https://en.wikipedia.org/wiki/360-day_calendar -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Use of term Master/Slave
On 1 August 2017 at 09:13, wrote: > Wondering why PostgreSQL still uses the terms master and slave when there > are other terms like primary/secondary that can be used in the same manner. Another alternative I've seen in different fields is "manager" and "agent". -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
