Documentation for varbit is missing size parameter
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/10/static/datatype.html
Description:
The documentation for the varbit data type is missing the size parameter "[
(n) ]".
2018-03-11 1:43 GMT-03:00 PG Doc comments form <noreply@postgresql.org>:
The documentation for the varbit data type is missing the size parameter "[
(n) ]".
Good catch! It seems to be an oversight in commit
768b647ead78d0d63915c1708cad13c2468f9440. The attached patch adds it.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Attachments:
doc2.difftext/x-patch; charset=US-ASCII; name=doc2.diffDownload+1-1
On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Taveira wrote:
2018-03-11 1:43 GMT-03:00 PG Doc comments form <noreply@postgresql.org>:
The documentation for the varbit data type is missing the size parameter "[
(n) ]".Good catch! It seems to be an oversight in commit
768b647ead78d0d63915c1708cad13c2468f9440. The attached patch adds it.
Wow, that commit is from 2004. Patch applied and backpatched to v10.
--
Bruce Momjian <bruce@momjian.us> 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 +
On Fri, Mar 30, 2018 at 5:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Taveira wrote:
2018-03-11 1:43 GMT-03:00 PG Doc comments form <noreply@postgresql.org>:
The documentation for the varbit data type is missing the size
parameter "[
(n) ]".
Good catch! It seems to be an oversight in commit
768b647ead78d0d63915c1708cad13c2468f9440. The attached patch adds it.Wow, that commit is from 2004. Patch applied and backpatched to v10.
If it goes all the way back to 2004, why not backpatch further?
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
On Fri, Mar 30, 2018 at 05:39:46PM +0200, Magnus Hagander wrote:
On Fri, Mar 30, 2018 at 5:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Taveira wrote:
2018-03-11 1:43 GMT-03:00 PG Doc comments form <noreply@postgresql.org>:
The documentation for the varbit data type is missing the size
parameter "[
(n) ]".
Good catch! It seems to be an oversight in commit
768b647ead78d0d63915c1708cad13c2468f9440. The attached patch adds it.Wow, that commit is from 2004.� Patch applied and backpatched to v10.
If it goes all the way back to 2004, why not backpatch further?
Uh, I am always debating how important it is to backpatck vs the churn
we require of translations of our docs. In this case, it didn't seem
worthwhile to have all of those translations try to deal with this
change for all those back branches.
--
Bruce Momjian <bruce@momjian.us> 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 +On Fri, Mar 30, 2018 at 6:26 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 30, 2018 at 05:39:46PM +0200, Magnus Hagander wrote:
On Fri, Mar 30, 2018 at 5:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Taveira wrote:
2018-03-11 1:43 GMT-03:00 PG Doc comments form <
noreply@postgresql.org>:
The documentation for the varbit data type is missing the size
parameter "[
(n) ]".
Good catch! It seems to be an oversight in commit
768b647ead78d0d63915c1708cad13c2468f9440. The attached patch addsit.
Wow, that commit is from 2004. Patch applied and backpatched to v10.
If it goes all the way back to 2004, why not backpatch further?
Uh, I am always debating how important it is to backpatck vs the churn
we require of translations of our docs. In this case, it didn't seem
worthwhile to have all of those translations try to deal with this
change for all those back branches.
If it's a clean backpatch I'd say it is -- people who are using PostgreSQL
9.6 will be reading the documentation for 9.6 etc, so they will not know
about the fix then.
If it's not a clean backpatch I can certainly see considering it, but if
it's not a lot of effort then I'd say it's definitely worth it.
I really don't think considerations for translators of the *docs* are an
issue here. If you don't backpatch it, then nobody gets the fix. If you
backpatch it, then English readers do get the fix, and translated docs
readers *might* get the fix, depending on how they are maintained. It's not
like translatable strings where if they change in a backbranch they will
revert to English unless the translation is updated -- for the docs, they
just don't get the fix.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
On Fri, Mar 30, 2018 at 06:28:15PM +0200, Magnus Hagander wrote:
On Fri, Mar 30, 2018 at 6:26 PM, Bruce Momjian <bruce@momjian.us> wrote:
Uh, I am always debating how important it is to backpatck vs the churn
we require of translations of our docs.� In this case, it didn't seem
worthwhile to have all of those translations try to deal with this
change for all those back branches.
If it's a clean backpatch I'd say it is -- people who are using PostgreSQL 9.6
will be reading the documentation for 9.6 etc, so they will not know about the
fix then.If it's not a clean backpatch I can certainly see considering it, but if it's
not a lot of effort then I'd say it's definitely worth it.I really don't think considerations for translators of the *docs* are an issue
here. If you don't backpatch it, then nobody gets the fix. If you backpatch it,
then English readers do get the fix, and translated docs readers *might* get
the fix, depending on how they are maintained. It's not like translatable
strings where if they change in a backbranch they will revert to English unless
the translation is updated -- for the docs, they just don't get the fix.�
My logic is that the more we backpatch, the less likely translators are
going to be to keep their docs up-to-date with minor releases since the
minor release diff is larger and contains more items that aren't
_required_ for correctness.
I looked at this patch and thought it was more a stylistic item rather
than a correction. Is that right?
--
Bruce Momjian <bruce@momjian.us> 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 +
On Friday, March 30, 2018, Bruce Momjian <bruce@momjian.us> wrote:
I looked at this patch and thought it was more a stylistic item rather
than a correction. Is that right?
Looks like a syntax bug fix to me - especially since it is a reference
table. Those should be back-patched.
David J.
On Fri, Mar 30, 2018 at 10:31:07AM -0700, David G. Johnston wrote:
On Friday, March 30, 2018, Bruce Momjian <bruce@momjian.us> wrote:
I looked at this patch and thought it was more a stylistic item rather
than a correction.� Is that right?Looks like a syntax bug fix to me - especially since it is a reference table.�
Those should be back-patched.
OK, now backpatched through 9.3.
--
Bruce Momjian <bruce@momjian.us> 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 +On Fri, Mar 30, 2018 at 7:34 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 30, 2018 at 10:31:07AM -0700, David G. Johnston wrote:
On Friday, March 30, 2018, Bruce Momjian <bruce@momjian.us> wrote:
I looked at this patch and thought it was more a stylistic item
rather
than a correction. Is that right?
Looks like a syntax bug fix to me - especially since it is a reference
table.
Those should be back-patched.
OK, now backpatched through 9.3.
Thanks!
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>