On Wed, 02 Oct 2002 18:48:49 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
I don't think it's really a good idea to expect users to pick among
multiple cost functions
The idea is that PG is shipped with a default representing the best of
our knowledge and users are not encouraged to change it. When
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I'd certainly be willing to do some testing on my own data with them.
Great!
Gotta patch?
Not yet.
I've found that when the planner misses, sometimes it misses
by HUGE amounts on large tables, and I have been
Tom Lane wrote:
Has anyone done the corresponding experiments on the other DBMSes to
identify exactly when they allow CURRENT_TIMESTAMP to advance ?
This applies up to Oracle 8.1.6, maybe it helps:
According to a co-worker, Oracle advances the time in transactions:
select to_char(sysdate,
I've been waiting to see how a patched file differs from my version.
The patch was added to the to apply list last week I think (it wasn't mine btw)
and I've been doing cvs diff to view the differences so I can tell when the
patch has been applied. Additional information given by this is the
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I'd certainly be willing to do some testing on my own data with them.
Gotta patch?
Yes, see below. Disclaimer: Apart from make; make check this is
completely untested. Use at your own risk. Have fun!
Servus
Hi everyone,
Have been thinking for a while now about viable ways to Open Source the
Flash based training material that has been in development from last
year.
After discussing this with a number of people for suggestions, feedback,
advise, etc, these are looking to be the general concepts
Hi,
Today we concluded test for database performance. Attached are results and the
schema, for those who have missed earlier discussion on this.
We have (almost) decided that we will partition the data across machines. The
theme is, after every some short interval a burst of data will be
At 11:06 AM 2/10/2002 -0400, Tom Lane wrote:
It needs to get done; AFAIK no one has stepped up to do it. Do you want
to?
My limited reading of off_t stuff now suggests that it would be brave to
assume it is even a simple 64 bit number (or even 3 32 bit numbers). One
alternative, which I am
My limited reading of off_t stuff now suggests that it would be brave to
assume it is even a simple 64 bit number (or even 3 32 bit numbers). One
alternative, which I am not terribly fond of, is to have pg_dump write
multiple files - when we get to 1 or 2GB, we just open another file, and
Lamar Owen [EMAIL PROTECTED] writes:
Builds fine here for RPM usage. Got an odd diff in the triggers regression
test: did we drop a NOTICE? If so, the regression output should probably
have been changed too.
No, we didn't change anything, and the 7.2 regression tests passed for
me on
Is anyone interested in translating the English version to other
languages?
I don't have time for the translation, unfortunately, but i would
suggest changing worlds to world's on the main page.
-tfo
---(end of broadcast)---
TIP 1: subscribe
Thomas O'Connell wrote:
Is anyone interested in translating the English version to other
languages?
I don't have time for the translation, unfortunately, but i would
suggest changing worlds to world's on the main page.
Um, doesn't world's mean world is ?
That wouldn't make sense then
Um, doesn't world's mean world is ?
In this situation, the 's denotes possession, as in the most advanced
open source database of the world.
worlds here is basically saying every world most advanced open source
database and does not, in any case, connote possession.
-tfo
On Thu, 03 Oct 2002 12:40:20 +0200, I wrote:
Gotta patch?
Yes, see below.
Oh, did I mention that inserting some break statements after the
switch cases helps a lot? :-(
Cavus venter non laborat libenter ...
Servus
Manfred
---(end of
Thomas F.O'Connell wrote:
Um, doesn't world's mean world is ?
In this situation, the 's denotes possession, as in the most advanced
open source database of the world.
worlds here is basically saying every world most advanced open source
database and does not, in any case, connote
Um, doesn't world's mean world is ?
i forgot to provide a real-world example:
http://www.amazon.com/
Earth's Biggest Selection
-tfo
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I've found that when the planner misses, sometimes it misses
by HUGE amounts on large tables,
Scott,
yet another question: are multicolunm indices involved in your
estimator problems?
Servus
Manfred
On Thu, 3 Oct 2002, Manfred Koizar wrote:
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I'd certainly be willing to do some testing on my own data with them.
Great!
Gotta patch?
Not yet.
I've found that when the planner misses, sometimes it
On Thu, 3 Oct 2002, Manfred Koizar wrote:
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I've found that when the planner misses, sometimes it misses
by HUGE amounts on large tables,
Scott,
yet another question: are multicolunm indices involved in your
On Thu, 3 Oct 2002 10:59:54 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
are multicolunm indices involved in your estimator problems?
No. Although I use them a fair bit, none of the problems I've encountered
so far have involved them. But I'd be willing to setup some test indexes
and
On Thursday 03 October 2002 12:46 pm, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Builds fine here for RPM usage. Got an odd diff in the triggers
regression test: did we drop a NOTICE? If so, the regression output
should probably have been changed too. The diff:
***
On Thursday 03 October 2002 12:29 am, Lamar Owen wrote:
RPMs will be uploaded either tonight or tomorrow morning after I get to
work; it will depend on how much upload bandwidth I can get out of this
dialup. It appears to be running OK, so I may let it run.
RPMS uploaded into the usual
On Wed, 2002-10-02 at 16:14, Marc G. Fournier wrote:
Just in case anyone enjoys these sorts of things :) It deals with the
whole .org TLD assignment ...
http://forum.icann.org/org-eval/gartner-report
I like this one:
| Unlike many of the conventional commercial databases,
Manfred Koizar [EMAIL PROTECTED] writes:
Never mind! I just stumbled over those lines in selfuncs.c where
indexCorrelation is calculated by dividing the correlation of the
first index column by the number of index columns.
Yeah, I concluded later that that was bogus. I've been thinking of
On Thu, Oct 03, 2002 at 04:00:32PM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we with this patch?
It's done as far as I'm concerned ;-). Not sure if Hannu still wants
to argue that the behavior is wrong ... it seems fine to me though ...
I still haven't
Good day,
I just stumbled across this peculiarity in PL/Perl today writing a method
to invoke Perl Regexes from a function: if a run-time error is raised in
an otherwise good function, the function will never run correctly again
until the connection to the database is reset. I poked around in
tom lane wrote:
But more globally, I think that our worst problems these days have to do
with planner misestimations leading to bad plans. The planner is
usually *capable* of generating a good plan, but all too often it picks
the wrong one. We need work on improving the cost modeling
I've been looking at the TODO lists and caching issues and think there may
be a way to greatly improve the performance of the WAL.
I've made the following assumptions based on my reading in the manual and
the WAL archives since about November 2000:
1) WAL is currently fsync'd before commit
Curtis Faith [EMAIL PROTECTED] writes:
Then during execution if the planner turned out to be VERY wrong about
certain assumptions the execution system could update the stats that led to
those wrong assumptions. That way the system would seek the correct values
automatically.
That has been
Some of you may be interested in this seemingly exhaustive benchmark
between ext2/3, ReiserFS, JFS, and XFS.
http://www.osdl.org/presentations/lwe-jgfs.pdf
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Curtis Faith [EMAIL PROTECTED] writes:
So, why don't we use files opened with O_DSYNC | O_APPEND for the WAL log
and then use aio_write for all log writes?
We already offer an O_DSYNC option. It's not obvious to me what
aio_write brings to the table (aside from loss of portability).
You still
Hey, excellent. Thanks!
Based on that, it appears that XFS is a pretty good FS to use. For me,
the real surprise was how well reiserfs performed.
Greg
On Thu, 2002-10-03 at 18:09, Mike Benoit wrote:
Some of you may be interested in this seemingly exhaustive benchmark
between ext2/3,
John Worsley [EMAIL PROTECTED] writes:
I just stumbled across this peculiarity in PL/Perl today writing a method
to invoke Perl Regexes from a function: if a run-time error is raised in
an otherwise good function, the function will never run correctly again
until the connection to the
On Thu, Oct 03, 2002 at 07:09:33PM -0400, Tom Lane wrote:
statement-arrival time. (I like the idea of a parameterized version of
now() to provide a consistent interface to all three functionalities.)
I like this, too. I think it'd be probably useful. But. . .
pride of place to
tom lane replies:
Curtis Faith [EMAIL PROTECTED] writes:
So, why don't we use files opened with O_DSYNC | O_APPEND for
the WAL log
and then use aio_write for all log writes?
We already offer an O_DSYNC option. It's not obvious to me what
aio_write brings to the table (aside from loss
Curtis Faith wrote:
The method I propose does not result in any blocking because of writes
other than the final commit's write and it has the very significant
advantage of allowing other transactions (from other back-ends) to
continue until they enter commit (and blocking waiting for their
Curtis Faith [EMAIL PROTECTED] writes:
The REAL issue and the one that will greatly affect total system
throughput is that of contention on the file locks. Since fsynch needs to
obtain a write lock on the file descriptor, as does the write calls which
originate from XLogWrite as the writes
I wrote:
My modification was to use access counts to increase the
durability of the
more accessed blocks.
tom lane replies:
You could do it that way too, but I'm unsure whether the extra
complexity will buy anything. Ultimately, I think an LRU-anything
algorithm is equivalent to a
I wrote:
The REAL issue and the one that will greatly affect total system
throughput is that of contention on the file locks. Since
fsynch needs to
obtain a write lock on the file descriptor, as does the write
calls which
originate from XLogWrite as the writes are written to the disk,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We have talked about possible return values for RULES, particularly
INSTEAD rule. Manfred has a nice example here, so I propose we handle
INSTEAD rules this way: that we return the oid and tuple count of the
last INSTEAD rule
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused how yours differs from mine. I don't see how the last
matching tagged query would not be from an INSTEAD rule.
You could have both INSTEAD and non-INSTEAD rules firing for the same
original query. If the alphabetically-last rule is a
On Fri, 2002-10-04 at 01:41, Bruce Momjian wrote:
Well, let's see what others say. If no one is excited about the change,
we can just document its current behavior. Oh, I see it is already
documented in func.sgml:
It is quite important to realize that
Oliver Elphick [EMAIL PROTECTED] writes:
I can see that the current behaviour might give surprising results in a
long running transaction. Surprise could be reduced by giving the time
of first use within the transaction rather than the start of the
transaction.
[ cogitates ... ] Hmm, we
Bruce Momjian wrote:
I may be missing something here, but other backends don't block while
one writes to WAL.
I don't think they'll block until they get to the fsync or XLogWrite
call while another transaction is fsync'ing.
I'm no Unix filesystem expert but I don't see how the OS can
handle
On Thu, Oct 03, 2002 at 10:26:16PM +1000, Justin Clift wrote:
Have been thinking for a while now about viable ways to Open Source the
Flash based training material that has been in development from last
year.
After discussing this with a number of people for suggestions, feedback,
advise,
On Thu, Oct 03, 2002 at 04:18:08PM -0400, Bruce Momjian wrote:
So, we have a couple of decisions to make:
Should CURRENT_TIMESTAMP be changed to statement arrival time?
Should now() be changed the same way?
If not, should now() and CURRENT_TIMESTAMP return the same type
Bruce Momjian [EMAIL PROTECTED] writes:
So, in summary, reasons for the change:
more intuitive
more standard-compliant
more closely matches other db's
I'd give you the first and third of those. As Andrew noted, the
argument that it's more standard-compliant is not very
At 07:15 AM 4/10/2002 +1000, Giles Lean wrote:
My limited reading of off_t stuff now suggests that it would be brave to
assume it is even a simple 64 bit number (or even 3 32 bit numbers).
What are you reading?? If you find a platform with 64 bit file
offsets that doesn't support 64 bit
Greg Copeland wrote:
-- Start of PGP signed section.
Hey, excellent. Thanks!
Based on that, it appears that XFS is a pretty good FS to use. For me,
the real surprise was how well reiserfs performed.
OK, hardware performance paper updated:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
So, in summary, reasons for the change:
more intuitive
more standard-compliant
more closely matches other db's
I'd give you the first and third of those. As Andrew noted, the
argument that it's more
Philip Warner writes:
Yes, but there is no guarantee that off_t is implemented as such, nor would
we be wise to assume so (most docs say explicitly not to do so).
I suspect you're reading old documents, which is why I asked what you
were referring to. In the '80s what you are saying would
Have people considered flock (advisory locking) on the postmaster.pid
file for backend detection? It has a nonblocking option. Don't most
OS's support it?
I can't understand why we can't get an easier solution to postmaster
detection than shared memory.
Just a reminder, we are not using this tag. All 7.3 patches are going
to HEAD. Once we decide to split the tree for 7.4, we will update this
branch and announce it is ready to be used.
---
Marc G. Fournier wrote:
As
Nigel J. Andrews wrote:
I've been waiting to see how a patched file differs from my version.
The patch was added to the to apply list last week I think (it wasn't mine btw)
and I've been doing cvs diff to view the differences so I can tell when the
patch has been applied. Additional
On 3 Oct 2002 at 19:33, Shridhar Daithankar wrote:
On 3 Oct 2002 at 13:56, Nigel J. Andrews wrote:
It's one hell of a DB you're building. I'm sure I'm not the only one interested
so to satisfy those of us who are nosey: can you say what the application is?
I'm sure we'll all understand
NOTE: Setting follow up to the performance list
Funny that the status quo seems to be if you need fast selects on data
that has few inserts to pick mysql, otherwise if you have a lot of
inserts and don't need super fast selects go with PostgreSQL; yet your
data seems to cut directly against
Nigel J. Andrews wrote:
cvs diff -r HEAD pltcl.c
gave me differences against revision 1.64
and cvs update pltcl.c
said it was merging changes between 1.64 and 1.61
and a plain cvs diff now shows me differences against 1.64
I think this is probably just a short fall in my fairly
has this patched been applied to the CVS yet?
On Tue, 1 Oct 2002, Zeugswetter
Andreas SB SD wrote:
Date: Tue, 1 Oct 2002 10:23:13 +0200
From: Zeugswetter Andreas SB SD [EMAIL PROTECTED]
To: Peter Eisentraut [EMAIL PROTECTED]
Cc: PostgreSQL Development [EMAIL PROTECTED]
Subject: Re: AIX
On 3 Oct 2002 at 8:54, Charles H. Woloszynski wrote:
Can you comment on the tools you are using to do the insertions (Perl,
Java?) and the distribution of data (all random, all static), and the
transaction scope (all inserts in one transaction, each insert as a
single transaction, some
Shridhar Daithankar wrote:
snip
Was the original posting on GENERAL or HACKERS. Is this moving the
PERFORMANCE for follow-up? I'd like to follow this discussion and want
to know if I should join another group?
Shall I subscribe to performance? What's the exat list name? Benchmarks? I
On Thu, 3 Oct 2002, Bruce Momjian wrote:
Nigel J. Andrews wrote:
cvs diff -r HEAD pltcl.c
gave me differences against revision 1.64
and cvs update pltcl.c
said it was merging changes between 1.64 and 1.61
and a plain cvs diff now shows me differences against 1.64
I
On Thu, 2002-10-03 at 10:56, Shridhar Daithankar wrote:
Well, we were comparing ext3 v/s reiserfs. I don't remember the journalling
mode of ext3 but we did a 10 GB write test. Besides converting the RAID to RAID-
0 from RAID-5 might have something to do about it.
There was a discussion on
On 3 Oct 2002 at 11:23, Greg Copeland wrote:
On Thu, 2002-10-03 at 10:56, Shridhar Daithankar wrote:
Well, we were comparing ext3 v/s reiserfs. I don't remember the journalling
mode of ext3 but we did a 10 GB write test. Besides converting the RAID to RAID-
0 from RAID-5 might have
Nigel J. Andrews wrote:
It gave me the log all the way up to the 1.64 revision with the REL7_3_STABLE
label assigned to revision 1.64.0.2
Revision 1.64 apparently backing out my patch which made 1.63.
I had a brain wave and did the cvs log command which was what lead me to try
specifying
Lamar Owen [EMAIL PROTECTED] writes:
Builds fine here for RPM usage. Got an odd diff in the triggers regression
test: did we drop a NOTICE? If so, the regression output should probably
have been changed too. The diff:
*** ./expected/triggers.out Sat Jan 15 14:18:23 2000
---
On Thu, 03 Oct 2002 21:47:03 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
I believe that was vacuum analyze only.
Well there is
VACUUM [tablename];
and there is
ANALYZE [tablename];
And
VACUUM ANALYZE [tablename];
is VACUUM followed by ANALYZE.
Servus
I said:
I am inclined to have the refint.c code emit the notice unconditionally
at DEBUG1 level, and then add a SET client_min_messages = DEBUG1 in
the triggers regression test to ensure the notice will appear.
Hmm, that doesn't look that good after all: the SET causes the
regression output
Hi Tino,
Tino Wildenhain wrote:
Hi Justin,
you want probably use the language-negotiation
rather then a query variable :-)
Um, language-negotiation in good in theory, but there are real world
scenarios it doesn't take into account. :(
However, the query variable is an override, and if
Nigel J. Andrews [EMAIL PROTECTED] writes:
I had a brain wave and did the cvs log command which was what lead me to try
specifying revisions. As I say it looks like a lack of knowledge about how cvs
works for these things. I always thought it worked like RCS and gave a diff
against the latest
Tom Lane wrote:
I said:
I am inclined to have the refint.c code emit the notice unconditionally
at DEBUG1 level, and then add a SET client_min_messages = DEBUG1 in
the triggers regression test to ensure the notice will appear.
Hmm, that doesn't look that good after all: the SET causes
Patch applied. Thanks.
---
Joe Conway wrote:
Masaru Sugawara wrote:
The previous patch fixed an infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
seems to occur even
Patch applied. Thanks.
---
Joe Conway wrote:
Tom Lane wrote:
It might work to measure time since the start of the whole process, or
until the timeout target, rather than accumulating adjustments to the
remains
Patch applied. Thanks.
---
Teodor Sigaev wrote:
This is small README fix for contrib/intarray. Thank you.
--
Teodor Sigaev
[EMAIL PROTECTED]
[ application/gzip is not supported, skipping... ]
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This will work nicely for the regression tests' purposes. If there is
anyone out there actually using refint.c in production, they might be
annoyed by the NOTICE chatter, but quite honestly I doubt anyone is ---
this contrib module has
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This will work nicely for the regression tests' purposes. If there is
anyone out there actually using refint.c in production, they might be
annoyed by the NOTICE chatter, but quite honestly I doubt anyone is ---
Patch applied. Thanks.
---
Mario Weilguni wrote:
It's just a cosmetic change, fixes the help screen. Should be applied in
/contrib/vacuumlo
Regards,
Mario Weilguni
[ Attachment, skipping... ]
Patch applied. Thanks.
---
Mario Weilguni wrote:
This small patch adds a Makefile for /contrib/reindexdb/ and renames the README to
README.reindexdb.
Regards,
Mario Weilguni
[ Attachment, skipping... ]
Samuel A Horwitz wrote:
has this patched been applied to the CVS yet?
No, I was waiting to see if there were any negative comments, but seeing
none, I will add it to the patch queue today.
---
On Tue, 1 Oct 2002,
I have added this to backend/libpq/README.SSL to be integrated into our
main docs later.
---
Bear Giles wrote:
A second cut at SSL documentation
SSL Support in PostgreSQL
=
Who needs
Tino Wildenhain wrote:
snip
Haha cutpaste ;-) Ever heard of csv? :-))
However, I can also have a look at it, if desired.
Heh Heh Heh
Good point. For the moment we've whipped up that MS Excel document
(created in OpenOffice of course) of all the English text strings in the
site and emailed
Thomas Lockhart wrote:
...
Seems that isn't helping enough to reduce the number of people who are
surprised by our behavior. I don't think anyone would be surprised by
statement time.
I think that there is no compelling reason for changing the current
behavior. There is no *single*
We have talked about possible return values for RULES, particularly
INSTEAD rule. Manfred has a nice example here, so I propose we handle
INSTEAD rules this way: that we return the oid and tuple count of the
last INSTEAD rule query with a tag matching the main query. The
returned tag, of
Jim, glad you are still around. Yes, we would love to get tablespaces
in 7.4. I think we need to think bigger and get something where we can
name tablespaces and place tables/indexes into these named spaces. I
can reread the TODO.detail stuff and give you an outline. How does that
sound?
Bruce Momjian [EMAIL PROTECTED] writes:
Have people considered flock (advisory locking) on the postmaster.pid
file for backend detection?
$ man flock
No manual entry for flock.
$
HPUX has generally taken the position of adopting both BSD and SysV
features, so if it doesn't exist here, it's
Giles Lean [EMAIL PROTECTED] writes:
When talking of near-current systems with 64 bit off_t you are not
going to find one without support for 64 bit integral types.
I tend to agree with Giles on this point. A non-integral representation
of off_t is theoretically possible but I don't believe
Tom Lane wrote:
Giles Lean [EMAIL PROTECTED] writes:
When talking of near-current systems with 64 bit off_t you are not
going to find one without support for 64 bit integral types.
I tend to agree with Giles on this point. A non-integral representation
of off_t is theoretically possible
At 11:07 PM 3/10/2002 -0400, Tom Lane wrote:
A non-integral representation
of off_t is theoretically possible but I don't believe it exists in
practice.
Excellent. So I can just read/write the bytes in an appropriate order and
expect whatever size it is to be a single intXX.
Fine with me,
Bruce Momjian [EMAIL PROTECTED] writes:
We have talked about possible return values for RULES, particularly
INSTEAD rule. Manfred has a nice example here, so I propose we handle
INSTEAD rules this way: that we return the oid and tuple count of the
last INSTEAD rule query with a tag matching
Lamar Owen [EMAIL PROTECTED] writes:
So the regression tests weren't really testing the actually built module, so
to speak. Is there a good reason to leave the NOTICE's in the expected
regression output?
Yes: without them the test is less useful, because you're less certain
that what
Adrian 'Dagurashibanipal' von Bidder wrote:
-- Start of PGP signed section.
On Wed, 2002-10-02 at 16:14, Marc G. Fournier wrote:
Just in case anyone enjoys these sorts of things :) It deals with the
whole .org TLD assignment ...
http://forum.icann.org/org-eval/gartner-report
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Zeugswetter Andreas SB SD wrote:
and
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Interesting. The inconsistency you're seeing is a result of GEQO. I
would have hoped that it would have produced a better quality plan
more often, but apparently not. On my system, the regular query
optimizer handily beats GEQO for
On Thursday 03 October 2002 02:31 pm, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
One thing that confuses me though is that the build options have been
like this for a long time (at least since 7.1). Why haven't you seen
this problem before? Did you recently change the way the RPMs
Where are we with this patch?
---
Alvaro Herrera wrote:
On 29 Sep 2002, Hannu Krosing wrote:
On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would
Tino Wildenhain [EMAIL PROTECTED] wrote:
Hi Justin,
Good point. For the moment we've whipped up that MS Excel document
(created in OpenOffice of course) of all the English text strings in the
site and emailed it to the volunteers. :)
Btw. did you ever unzip the native OpenOffice (aka
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
Sent: 01 October 2002 21:05
To: Dave Page
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [HACKERS] psqlODBC *nix Makefile (new 7.3 open item?)
Dave Page writes:
majority of you!) knock up a
Tom Lane wrote:
Has anyone done the corresponding experiments on the other DBMSes to
identify exactly when they allow CURRENT_TIMESTAMP to advance ?
I have Db2 on hand and examined CURRENT TIMESTAMP in an sql procedure.
(IBM have implemented it without the _ )
The short of it is that
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we with this patch?
It's done as far as I'm concerned ;-). Not sure if Hannu still wants
to argue that the behavior is wrong ... it seems fine to me though ...
regards, tom lane
---(end of
[ Thread moved to hackers.]
OK, I have enough information from the various other databases to make a
proposal. It seems the other databases, particularly Oracle, record
CURRENT_TIMESTAMP as the time of statement start. However, it isn't the
time of statement start from the user's perspective,
On Fri, 2002-10-04 at 01:00, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we with this patch?
It's done as far as I'm concerned ;-). Not sure if Hannu still wants
to argue that the behavior is wrong ... it seems fine to me though ...
I stop arguing for now, ONLY can
1 - 100 of 103 matches
Mail list logo
