[DOCS] "May", "can", "might"
Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". I would like to clean up our documentation to consistently use these words. Objections? (Who says were obsessive?) :-) -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] "May", "can", "might"
On 1/31/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". I would like to clean up our documentation to consistently use these words. Objections? My full support. :} I like clarity, specially on such important things as communication! (Who says were obsessive?) :-) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] "May", "can", "might"
Andrej Ricnik-Bay wrote: > On 1/31/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > Standard English uses "may", "can", and "might" in different ways: > > > > may - permission, "You may borrow my rake." > > > > can - ability, "I can lift that log." > > > > might - possibility, "It might rain today." > > > > Unfortunately, in conversational English, their use is often mixed, as > > in, "You may use this variable to do X", when in fact, "can" is a better > > choice. Similarly, "It may crash" is better stated, "It might crash". > > > > I would like to clean up our documentation to consistently use these > > words. Objections? > My full support. :} I like clarity, specially on such important things > as communication! > > > > (Who says were obsessive?) :-) Ah, someone already got me with were -> we're. "Who says we're obsessive?" Perfect! -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] "May", "can", "might"
Bruce Momjian a écrit : Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". I would like to clean up our documentation to consistently use these words. Objections? No objections at all... it can only ease translations. (Who says were obsessive?) :-) :) -- Guillaume. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[DOCS] Re: [BUGS] BUG #2913: Subscript on multidimensional array yields no value
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> This is not a bug, this is a definitional disagreement, and your TODO
> >> entry presupposes an answer that I don't particularly agree with.
>
> > Well, our documentation suggests thaat [1] is the same as [1:1]:
> > http://www.postgresql.org/docs/8.2/static/arrays.html#AEN5791
>
> It says absolutely no such thing. A subscript expression involving m:n
> produces a "slice", hence an array of different dimensionality from the
> original, whereas a subscript expression not involving any colon
> produces a single element --- that is, not an array at all.
>
> You could make a fair case that the (ARRAY[[1,2],[3,4]])[1] example
> should throw an error instead of returning null. But to claim it is
> the same as a slice expression is a typing violation.
[ moved to docs list ]
Well, I don't understand our array documentation, so odds are others
don't either. What are we saying here:
An array slice is denoted by writing lower-bound:upper-bound for one or
more array dimensions. For example, this query retrieves the first item
on Bill's schedule for the first two days of the week:
SELECT schedule[1:2][1:1] FROM sal_emp WHERE name = 'Bill';
schedule
{{meeting},{training}}
(1 row)
We could also have written
SELECT schedule[1:2][1] FROM sal_emp WHERE name = 'Bill';
with the same result. An array subscripting operation is always taken to
represent an array slice if any of the subscripts are written in the
form lower:upper. A lower bound of 1 is assumed for any subscript where
only one value is specified, as in this example:
What is the difference between 'lower-bound:upper-bound' and
'lower:upper'? Here are the items that confuse me:
test=> SELECT (ARRAY[[1,2],[3,4]])[1][1];
array
---
1
(1 row)
test=> SELECT (ARRAY[[1,2],[3,4]])[1:1];
array
-
{{1,2}}
(1 row)
test=> SELECT (ARRAY[[1,2],[3,4]])[1];
array
---
(1 row)
The first two make sense to me, but the last one does not. If someone
explains it, I can update our documentation.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
