>
>
> You might want to review the Theories of Relativity, which pretty much blew
> away
> the notion of an absolute time and introduced the notion of frame of
> reference
> for time.
>
>
Well, I give up.
--
Hernán J. González
http://hjg.com.ar/
On Sat, Jun 25, 2011 at 3:56 AM, David Johnston wrote:
> First: I would suggest your use of “Local Time” is incorrect and that you
> would be better off thinking of it as “Abstract Time”. My responses below
> go into more detail but in short you obtain a “Local” time by “Localizing”
> and “Abstr
> As I understand it, documentation patches are welcomed:)
I'd indeed wish some radical changes to the documentation.
To start with, the fundamental data type names are rather misleading; SQL
standard sucks here, true, but Postgresql also has its idiosincracies, and
the docs do not help much:
ht
>
>
> Every example here starts, at its core, with to_timestamp. That function
> returns a timestamp *with* time zone so of-course the current timezone
> setting will influence it. Stop using it - it doesn't do what you want.
>
> If you cast directly to a timestamp *without* time zone you can take
On Thu, Jun 23, 2011 at 4:15 PM, Adrian Klaver wrote:
> On 06/23/2011 11:40 AM, hernan gonzalez wrote:
>
>>Rather than being not viable, I'd argue that is is not correct.
>>Rather, a simple direct cast will suffice:
>>'2011-12-30 00:30:00'::ti
> Rather than being not viable, I'd argue that is is not correct. Rather, a
> simple direct cast will suffice:
> '2011-12-30 00:30:00'::timestamp without time zone
>
That works only for that particular format. The point is that, for example,
if I have some local date time
stored as a string in ot
There is some related discussion here
http://postgresql.1045698.n5.nabble.com/to-timestamp-returns-the-incorrect-result-for-the-DST-fall-over-time-td3327393.html
But it amounts to the same thing: TO_TIMESTAMP() is not apt for dealing with
plain TIMESTAMP
(without time zones).
Hence, there is no f
to_timestamp() returns a TIMESTAMP WITH TIME ZONE
Perhaps an alternative that returns a TIMESTAMP WITHOUT TIME ZONE (which,
BTW, is the default TIMESTAMP)
should be provided. Elsewhere, there is no direct-robust way of parsing
a TIMESTAMP WITHOUT TIME ZONE (which
represesents a "local date-time"
I plan to define two domains with no contraints, sort of typedefs, to
work with date-times inside my application:
CREATE DOMAIN instant AS timestamp(3) with time zone;
CREATE DOMAIN localdatetime AS timestamp(3) without time zone;
Two questions:
1. I guess that there is no performance penalty
> There are any number of
> server-side settings that can affect the interpretation (and display)
> of your data. Datestyle for example already renders this position
> untenable.
What makes me a little uncomfortable in this assertion -and in many
parts of PG docs-
is that emphasis put on what "is
I'm doing some tests with date-time related fields to design my web
application.
I was already dissatisfied with Postgresql handling of timezones
concepts (issue
already discussed here - not entirely PG's fault, rather a SQL thing)
and I vehemently
reject the idea of a global server-side timezone
Most examples in the array documentation uses ARRAY[1,2,3] and similar.
http://www.postgresql.org/docs/9.0/interactive/functions-array.html
I think (actually I have experienced it, both in myself and others)
that this can be misleading in some cases.
For example: array_upper(ARRAY[1,2,3,4], 1)
Replacing that 1 for 2 it's enough for making it work, for me, it seems.
But it's not enough to get valgrind happy (It still reports 4 "definitely
lost" blocks, all from that putenv2 function). Perhaps that's related to the
comment:
/*
* Do not free envstr because it becomes pa
In pg_upgrade/controldata.c , putenv2 function :
char *envstr = (char *) pg_malloc(ctx, strlen(var)
+ strlen(val) + 1);
sprintf(envstr, "%s=%s", var, val);
Shouldn't it be "+ 2 " instead of "+ 1" ? (one for the '=', plus one for
the null terminating char) ?
I think that
2010/11/2 hernan gonzalez
> 2010/11/2 Grzegorz Jaśkiewicz
>
> try gdb --args ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D
>> /var/pgsql-9_0_1/data/ -b /var/pgsql-8_4_3/bin/ -B
>> /var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G debug
>> and when it fails, type in &#
2010/11/2 Grzegorz Jaśkiewicz
> try gdb --args ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D
> /var/pgsql-9_0_1/data/ -b /var/pgsql-8_4_3/bin/ -B
> /var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G debug
> and when it fails, type in 'bt' and paste it here please.
>
> --
> GJ
>
Well, this is strange. I
I am stuck with a segmentation fault while running pg_upgrade, from 8.4.3 to
9.0.1
$ ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D /var/pgsql-9_0_1/data/ -b
/var/pgsql-8_4_3/bin/ -B /var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G
debug
Running in verbose mode
Running in debug mode
PerForming Consistenc
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 cha
Sorry about a error in my previous example (mixed width and precision).
But the conclusion is the same - it works on bytes:
#include
main () {
char s[] = "ni\xc3\xb1o"; /* 5 bytes , 4 utf8 chars */
printf("|%*s|\n",6,s); /* this should pad a black */
printf("|%.*s|\n",4,s);
Mmm no: \x displays correctly for me because it sends
the raw text (in LATIN9) and I have set my terminal in LATIN9 (or ISO-8859-15)
And it's not that "xterm is misdisplaying" the text, it just that psql
is ouputting
an EMPTY (zero lenght) string for that field.
(I can even send the output to a
It's surely not a xterm problem, I see the characters ok with just the
\x formatting. I can check also the output redirecting to a file.
My original client_encoding seems to be LATIN9 in both cases,
accorging to the \set ouput.
If I change it (for the root user) to UTF8 with " SET CLIENT_ENCODING
(Disclaimer: I've been using Postgresql for quite a long time, I
usually deal with non-ascii LATIN-9 characters ,
but that has never been a problem, until now)
My issue summarized: when psql is invoked from a user who has a locale
different from that of the database, the tabular output
is wrong fo
I was thinking thinking about the issue asked here, about an error in
a query causing the whole transaction to abort,
http://stackoverflow.com/questions/2741919/can-i-ask-postgresql-to-ignore-errors-within-a-transaction/2745677
which has already bothered so many postgresql users and has been
discus
Another example (Psotgresql 8.3.0, UTF-8 server/client encoding)
test=# create table chartest ( c text);
test=# insert into chartest (c) values ('¡Hasta mañana!');
test=# create view vchartest as
select encode(convert_to(c,'LATIN9'),'escape') as c1 from chartest;
test=# select c,octet_length(c
> IMHO, the semantics of encode() and decode() are correct (the bridge
> between bytea and text ... in the backend encoding; they should be the
> only bridge), convert() is also ok (deals with bytes), but
> convert_to() and convert_from() are dubious if not broken: they imply
> texts in arbitrary e
> Umm, I think all you showed was that the to_ascii() function was
> broken. Postgres knows exactly what encoding the string is in, the
> backend encoding: in your case UTF-8.
That would be fine, if it were true; then, one could assume that every
postgresql function that returns a text gets ALW
> It seems to me that postgres is trying to do as you suggest: text is
> characters and bytea is bytes, like in Java.
But the big difference is that, for text type, postgresql knows "this
is a text"
but doesnt know the encoding, as my example showed. This goes against
the concept of "text vs byt
(After dealing a while with this, and learning a little, I though of
post this as comment in the docs, but perhaps someone who knows better
can correct or clarify)
=
The issues of charset encodings
d, speaks of the 'pg_option' file,
and doesn't mention those settings...
Help! Am I missing something stupid?
Hernan Gonzalez
Buenos Aires, Argentina
29 matches
Mail list logo
