[BUGS] unsubscribe
---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] "Julian day" date format is off by 12 hours
Postgres version: 8.0.6 Operating system: Ubuntu GNU/Linux I executed the following query while trying to build some date-conversion functions for data that was represented as milliseconds since the Unix epoch: davidl=# SELECT to_char(timestamp '1970-01-01 00:00:00 GMT','J MS'); to_char --- 2440588 0 000 (1 row) However, Postgres's notion of a "Julian Day" does not match the generally-accepted definition. According to the generally-accepted definition, the result of the query above should be 2440587 43200 000 ; that is, 12 hours past noon on Julian day 2440687, which started at noon on December 31st, 1969, GMT. I'm not sure if this should be regarded as a database bug or a documentation bug. Table 9-21 in the manual only says that a Julian day is "days since January 1, 4712 BC", so Postgres is consistent with the manual; but every other definition of a Julian day I've found says that it starts at noon. The Wikipedia article has several good references: http://en.wikipedia.org/wiki/Julian_day -- Software Developer, Precision Motor Transport Group, LLC Work phone 517-349-3011 x215 Cell phone 586-873-8813 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2818: ADO Field.Attributes reports NULL on NOT NULL fields
The following bug has been logged online:
Bug reference: 2818
Logged by: Brien R. Givens
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: Win XP
Description:ADO Field.Attributes reports NULL on NOT NULL fields
Details:
In ADO, the nullability of a field can be tested against its Attributes
property. Another option is to examine the Schema. As shown below, the
Attributes property of a NOT NULL field indicates it is nullable while the
Schema reports that it is not.
ADO Code:
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Driver={PostgreSQL
ANSI};Server=localhost;Database=clinic;UID=clinic;PWD=c0nner99"
conn.Execute "DROP TABLE test"
conn.Execute "CREATE TABLE test (f1 INT NOT NULL)"
Set rs = Server.CreateObject("ADODB.recordset")
rs.Open "test", conn, adOpenStatic, adLockReadOnly, adCmdTableDirect
Response.Write ((rs(0).Attributes And adFldIsNullable) = adFldIsNullable) &
""
rs.Close
Set rs = conn.OpenSchema(adSchemaColumns,Array(Empty,Empty,"test","f1"))
Response.Write rs("IS_NULLABLE")
rs.Close
conn.Close
-- OUTPUT --
True
False
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [BUGS] BUG #2802: Feature request: tinyint and unsigned types
On Dec 4, 2006, at 4:11 PM, Bruno Wolff III wrote: You can already use "char" to store 1 byte values, though unless there are several of these in a row, you won't save any space because of alignment. There's also boolean... Is there any technical reason why we don't support unsigned ints or tinyint? Just a matter of no one feeling the itch? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2802: Feature request: tinyint and unsigned types
Jim Nasby <[EMAIL PROTECTED]> writes: > Is there any technical reason why we don't support unsigned ints or > tinyint? Just a matter of no one feeling the itch? The question is whether it's worth complicating the numeric-type promotion hierarchy even more. A variant int type probably isn't worth much if it doesn't interact naturally with arithmetic & comparisons with other int types, but we've found out the hard way that you can't have a huge number of possible interpretations, or you get too many "can't resolve which operator to use" errors. (See the archives for details.) My private suspicion is that 90% of the people who say they want tinyint are really looking for a enum type, and thus that Tom Dunstan's recent patch for enum support might solve their problem. (Did Tom's patch allow for the storage size to vary depending on the number of values? Those folk won't be satisfied if not, even though we all know that alignment issues frequently negate any savings...) As for unsigned, you can use OID as uint4 if you must. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
