Hmm. I am reminded of Knuth's famous dictum: never generate random
numbers with a method chosen at random. Is there any actual theory
behind that algorithm, and if so what is it? The combination of
shifting with addition (not xor) seems more likely to lead to weird
cancellations than any
Wow, you are right, this is bizarre...
And it's not that glibc intends to compute the length in unicode chars,
it actually counts bytes (c plain chars) -as it should- for computing
field widths...
But, for some strange reason, when there is some width calculation involved
it tries so parse the
Sorry about a error in my previous example (mixed width and precision).
But the conclusion is the same - it works on bytes:
#includestdio.h
main () {
char s[] = ni\xc3\xb1o; /* 5 bytes , 4 utf8 chars */
printf(|%*s|\n,6,s); /* this should pad a black */
hernan The support of timezones is really crippled
hernan now.
Crippled how?
Well, among other things, no builtin date-timetype allows me to save
the timezone (or even the offset).
No type allows to treat this three datetimes as different values.
'2010-07-27 10:30 GMT+4' '2010-07-27 09:30
Are there any plans to (is anybody working on) implement better
timezone support in postgresql
for 8.5 ? Specifically, store the timezone info -instead of just the
timestamp as UTC ?
http://wiki.postgresql.org/wiki/Todo#Dates_and_Times
Hernán J. González
--
Sent via pgsql-hackers mailing list
Perhaps the OP should explain exactly what real-world problems he's
trying to solve. As noted in the discussion you linked, there's not
a lot of enthusiasm around here for getting closer to the spec's
datetime handling simply because it's the spec; that part of the spec
is just too broken
Postgresql 8.4 beta1 does not compile in win-XP3 because of the
already reported bug (#4662)
http://archives.postgresql.org/pgsql-bugs/2009-04/msg00142.php
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00367.php
The patch mentioned in those posts fixed the problem for me
Hernán J.
Hi.
As I wanted to change the order of columns of some tables (I know, I
know, my code does not depend
on that; but I prefer that \dt gives me a more organized ouput...)
I've added an option to pg_dump to reorder
columns in the ouput CREATE TABLE dump.
The specified order is given in a external
On Fri, Nov 14, 2008 at 4:12 PM, Tom Lane [EMAIL PROTECTED] wrote:
hernan gonzalez [EMAIL PROTECTED] writes:
I've added an option to pg_dump to reorder
columns in the ouput CREATE TABLE dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool