On Mon, Sep 30, 2002 at 06:31:15PM -0400, Tom Lane wrote:
The middle part of that boils down (as of today) to
regression=# select to_date('402002', 'WW');
to_date
2002-10-01
(1 row)
and Oct 1 (tomorrow) is Tuesday. As to why it picks that day to
represent Week 40
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
Sent: 30 September 2002 21:11
To: Dave Page
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] psqlODBC *nix Makefile (new 7.3 open item?)
Dave Page writes:
Can someone who knows make
On Mon, Sep 30, 2002 at 05:37:47PM -0400, Rod Taylor wrote:
select to_char(
to_date(
CAST(extract(week from CURRENT_TIMESTAMP) as text)
|| CAST(extract(year from CURRENT_TIMESTAMP) as text)
, 'WW')
, 'FMDay, D');
to_char
Tuesday, 3
(1 row)
Hello!
BTW, is it possible to have just patch against previous version (to reduce
traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz?
--
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: [EMAIL PROTECTED]
Unix is like a
Attached is a patch to fix the mb linking problems on AIX. As a nice side effect
it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so
(all shlibs that are not postmaster loadable modules).
Can you explain the method behind your patch? Have you tried -bnogc?
Is it my imagination, or is there a problem with the way pg_dump uses off_t
etc. My understanding is that off_t may be 64 bits on systems with 32 bit
ints. But it looks like pg_dump writes them as 4 byte values in all cases.
It also reads them as 4 byte values. Does this seem like a problem
Karel Zak [EMAIL PROTECTED] writes:
What think about it our Toms?
...
In the Oracle it's same (means WW vs. IW vs. D)
If it works the same as Oracle then I'm happy with it; that's what it's
supposed to do.
The real point here seems to be that EXTRACT(week) corresponds to
to_date's IW
Philip Warner [EMAIL PROTECTED] writes:
Is it my imagination, or is there a problem with the way pg_dump uses off_t
etc. My understanding is that off_t may be 64 bits on systems with 32 bit
ints. But it looks like pg_dump writes them as 4 byte values in all cases.
It also reads them as 4
I noticed that some of my queries don't work anymore because they're using
the floor function:
e.g.: select type, floor(date_part('epoch', dataend)) as ts from
last_modified
Why is floor not working anymore? I guess I can use round too, but I don't
want to modify semantics.
Regards,
Mario Weilguni [EMAIL PROTECTED] writes:
I noticed that some of my queries don't work anymore because they're using
the floor function:
e.g.: select type, floor(date_part('epoch', dataend)) as ts from
last_modified
Why is floor not working anymore?
Mph. Seems we have floor(numeric) but not
If it's of any use the following link gives some info on different schemes
and details on an ISO week numbering standard.
http://www.merlyn.demon.co.uk/weekinfo.htm#WkNo
Best Regards,
Tim Knowles
---(end of broadcast)---
TIP 1: subscribe and
Alexey V. Borzov writes:
Agh! I finally read up on module loading
http://developer.postgresql.org/docs/postgres/xfunc-c.html#XFUNC-C-DYNLOAD
and now I seem to understand. You see, the problem with the current
Makefile is as follows: it substitutes '$libdir' into both .sql and
perl
Tom Lane writes:
Yes, it does --- the implication is that the custom format, at least,
can't support dumps 4Gb. What exactly is pg_dump writing off_t's
into files for; maybe there's not really a problem?
That's kind of what I was wondering, too.
Not that it's an excuse, but I think that
what's the default lock in pgsql?
if I issued insert(copy)/or update processed
on the same table but on different records
the same time, how those processes will
affect each other?
thanks.
johnl
---(end of broadcast)---
TIP 3: if
On Tue, Oct 01, 2002 at 03:30:38PM -0500, John Liu wrote:
what's the default lock in pgsql?
if I issued insert(copy)/or update processed
on the same table but on different records
the same time, how those processes will
affect each other?
You might want to check out the docs at
What is the reason for maintaining separate rscale and dscale values in
numeric variables?
I am finding that this arrangement leads to some odd results, for
example this:
regression=# select (exp(ln(2.0)) - 2.0);
?column?
-
-0.
(1 row)
regression=#
On Tue, 1 Oct 2002, John Liu wrote:
what's the default lock in pgsql?
if I issued insert(copy)/or update processed
on the same table but on different records
the same time, how those processes will
affect each other?
postgresql does not do locking in the sense of how most database do
At 09:59 AM 1/10/2002 -0400, Tom Lane wrote:
If there is a problem, seems like we'd better fix it. Perhaps there
needs to be something in the header to tell the reader the sizeof
off_t.
Yes, and do the peripheral stuff to support old archives etc. We also need
to be careful about the places
I noticed some other minor differences between 7.2 and 7.3:
* 7.2: select now() + '1 minute'::timespan = works
* 7.2: select now() + '1 minute'::reltime = works
* 7.3: select now() + '1 minute'::timespan = does not work (Type timespan does not
exist)
* 7.3 select now() + '1 minute'::reltime =
Yury Bokhoncovich wrote:
Hello!
BTW, is it possible to have just patch against previous version (to reduce
traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz?
In some releases, it is possible, in others we add/remove files and it
isn't possible. I think because it isn't always
Hello!
On Tue, 1 Oct 2002, Bruce Momjian wrote:
In some releases, it is possible, in others we add/remove files and it
isn't possible. I think because it isn't always possible we normally
don't do it.
I think it's enough to do diffs for minor release (i.e. 7.2.2-7.2.3,
7.3.0-7.3.1 and so
Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Is it my imagination, or is there a problem with the way pg_dump uses off_t
etc. My understanding is that off_t may be 64 bits on systems with 32 bit
ints. But it looks like pg_dump writes them as 4 byte values in all cases.
It
Bruce Momjian writes:
BTW, is it possible to have just patch against previous version (to reduce
traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz?
In some releases, it is possible, in others we add/remove files and it
isn't possible. I think because it isn't always possible we
Dave Page writes:
majority of you!) knock up a makefile so the driver will build
standalone on *nix systems please? There should be no
dependencies on
any of the rest of the code - certainly there isn't for the Win32
build.
I'm working something out. I'll send it to you
Peter Eisentraut wrote:
Bruce Momjian writes:
BTW, is it possible to have just patch against previous version (to reduce
traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz?
In some releases, it is possible, in others we add/remove files and it
isn't possible. I think
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Adding or removing files isn't the problem (see -N option). Binary files
are the problem.
Do we change any binary files in minor releases, or even major ones?
But the source distribution hasn't *got* any binary files.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Adding or removing files isn't the problem (see -N option). Binary files
are the problem.
Do we change any binary files in minor releases, or even major ones?
But the source distribution hasn't *got*
Hi all,
Over the last few weeks we've put together a new Advocacy and
Marketing website for PostgreSQL:
http://advocacy.postgresql.org
It's now ready for public release. It has the first few case studies,
lists the major advantages to PostgreSQL, and provides a place you can
point your CIO,
At 11:20 AM 1/10/2002 -0400, Bruce Momjian wrote:
BSD/OS has 64-bit off_t's so it does support large files. Is there
something I can test?
Not really since it saves only the first 32 bits of the 64 bit positions it
will do no worse than a version that supports 32 bits only. It might even
do
29 matches
Mail list logo
