Re: [SQL] Date problem
>> Ok. Let's work. I posted a mail before explaining a strange >> cituation if my Postgresql: when I use date_part() function to split >> day, month and year of a date type column, it returns one day before. >> In other words, '2000-01-01' returns day: 31, month:12, year: 1999. > No problem here. Or on PG-ACCESS. There's a known (and fixed for 7.1) bug of this sort that occurs on spring daylight-savings-time transition days: the date-to-timestamp conversion function picks the wrong timezone offset to interpret "midnight" in, yielding a timestamp for 11PM of the prior date. On the fall DST date, you get a timestamp for 1AM. For example, in USA zones: play=> select '2000-04-02'::date::timestamp; ?column? 2000-04-01 23:00:00-05 (1 row) play=> select '2000-10-29'::date::timestamp; ?column? 2000-10-29 01:00:00-04 (1 row) Not sure how this would apply to 2000-01-01, though. What timezone are you in, anyway? regards, tom lane
Re: [SQL] Date problem
Elipo,
> Ok. Let's work. I posted a mail before explaining a strange
> cituation if my Postgresql: when I use date_part() function to split
> day, month and year of a date type column, it returns one day before.
> In other words, '2000-01-01' returns day: 31, month:12, year: 1999.
No, I was hoping an expert would take this on. Lemme test it on Linux:
create table test_date AS (
haveadate DATE );
insert into test_date ( haveadate )
values ( '2000-04-30' );
select haveadate, date_part('month',haveadate),
date_part('day',haveadate),
date_part('year',haveadate) from test_date
haveadate
2000-04-30 4 30 2000
No problem here. Or on PG-ACCESS.
The problem must be in the OS/2 compile, probably some problem in
accessing the internal clock?
-Josh
--
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (415) 436-9166
for law firms, small businesses fax 436-0137
and non-profit organizations. pager 338-4078
San Francisco
[SQL] Date problem
Hi all, Hi all, Before all, a little (off-topic) comment: >It's been my experience that Win32 ODBC does not drop >connections until the database client is closed (e.g. MS >Access is shut down). "There is some things that only Micro$oft can do for you..." Ok. Let's work. I posted a mail before explaining a strange cituation if my Postgresql: when I use date_part() function to split day, month and year of a date type column, it returns one day before. In other words, '2000-01-01' returns day: 31, month:12, year: 1999. I'm using OS/2 with Fix Pack 12, Postgresql 7.0.2. Can any one explain this? []'s Edipo Elder F. de Melo
Re: [SQL] memory usage
John Hasler wrote: > > Carolyn Wong writes: > > This program seems to use a lot of the memory on the linux server, and > > the memory doesn't seem to be released at the end of execution. > > Are you quite certain that this is actually what is happening? Linux > memory usage can be confusing. I run 'top' to see cpu usage when running the program. The 'postmaster' command seems to stay after my program terminates. Because the program runs every 10 minutes, when it restarts, the mem usage for the same command increases. > -- > John Hasler > [EMAIL PROTECTED] (John Hasler) > Dancing Horse Hill > Elmwood, WI
Re: [SQL] transactions surrounding extension functions
Forest Wilkinson writes: > Does this mean that when I call a function I wrote, which is composed > of several queries, each of those queries will be executed in its own > transaction? No > Or, will the statement containing the function call be executed in its > own transaction, thereby including all the queries composing my > function in that same transaction? Yes -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[SQL] transactions surrounding extension functions
According to the postgres 7 docs: >By default, Postgres executes transactions in unchained mode (also >known as “autocommit” in other database systems). In other words, each >user statement is executed in its own transaction and a commit is >implicitly performed at the end of the statement (if execution was >successful, otherwise a rollback is done). Does this mean that when I call a function I wrote, which is composed of several queries, each of those queries will be executed in its own transaction? Or, will the statement containing the function call be executed in its own transaction, thereby including all the queries composing my function in that same transaction? This is important when I have a function that performs a SELECT...FOR UPDATE, followed by an UPDATE to the selected rows. If I call that function without surrounding it with BEGIN and END, the former behavior would be dangerous, while the latter behavior would be desirable. Thanks, Forest Wilkinson
Re: [SQL] memory usage
Carolyn Wong writes: > This program seems to use a lot of the memory on the linux server, and > the memory doesn't seem to be released at the end of execution. Are you quite certain that this is actually what is happening? Linux memory usage can be confusing. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
