Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On 23 June 2010 02: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. > Okay. I'll admit that this won't be a common case, but could the error message make reference to the value it took? Thom -- 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
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On Wed, Jun 23, 2010 at 10:29 AM, Mike Toews wrote: > 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]+) You can't assume that a dash followed by digits is always a negative number. Consider: SELECT 10-4; If you we interpret this as "10" followed by "-4", it's a syntax error. You have to treat it as a separate token and work out later whether it's a binary operator or a prefix operator. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] hot standby documentation
On Tue, 2010-06-22 at 14:24 -0400, Robert Haas wrote: > Fixed. See attached. I started reading this but by chunk seven I only agree with a couple of these changes. None of them seem hugely important changes. I'd suggest you make a pass of copy editing that doesn't seek to alter the meanings or add information, so we can agree without discussing each proposed change in detail. Definitely don't remove information. It's not impossible to believe that temp tables could be written in the future, so I disagree with the comments there. We could also allow SELECT ... FOR SHARE during Hot Standby, simply by making it same as normal SELECT, without any ill effects. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] hot standby documentation
On Wed, Jun 23, 2010 at 2:53 PM, Simon Riggs wrote: > On Tue, 2010-06-22 at 14:24 -0400, Robert Haas wrote: > >> Fixed. See attached. > > I started reading this but by chunk seven I only agree with a couple of > these changes. None of them seem hugely important changes. > > I'd suggest you make a pass of copy editing that doesn't seek to alter > the meanings or add information, so we can agree without discussing each > proposed change in detail. Definitely don't remove information. I've actually removed very little. The current text repeats some information or splits up related facts across different paragraphs. > It's not impossible to believe that temp tables could be written in the > future, so I disagree with the comments there. The text I wrote does not say that temp tables could not be written in the future. It simply says why they cannot be written now. > We could also allow SELECT ... FOR SHARE during Hot Standby, simply by > making it same as normal SELECT, without any ill effects. True. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] hot standby documentation
On Wed, Jun 23, 2010 at 3:05 PM, Robert Haas wrote: >> We could also allow SELECT ... FOR SHARE during Hot Standby, simply by >> making it same as normal SELECT, without any ill effects. > > True. Actually, wait a minute. Why wouldn't we need to lock the tuples on the standby just as we do on the primary? Sure, there can't be another user transaction modifying those tuples, but WAL replay could still modify them. Anyhow, I think that's beside the point. The documentation just says what Hot Standby does, not what it might do in a future release. And I don't think this patch changes that very much at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] hot standby documentation
On 23/06/10 22:05, Robert Haas wrote: On Wed, Jun 23, 2010 at 2:53 PM, Simon Riggs wrote: We could also allow SELECT ... FOR SHARE during Hot Standby, simply by making it same as normal SELECT, without any ill effects. True. Not really. It won't matter while the standby is in read-only mode, but as soon as the server is promoted to master, you could have other backends modifying rows that the still-running "SELECT ... FOR SHARED" transaction should have locked. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
