Fixes committed.
- Thomas
Fix up "Postgres-style" time interval representation when fields have
mixed-signs. Previous effort left way too many minus signs, and was at
least as broken as the one before that :(
Clean up "ISO-style" time interval representation to omit zero f
Does anyone know if this feature exists? If so, what version or where
can a patch be obtained?
Thanks
--- Forwarded message follows ---
Date sent: Mon, 15 Jan 2001 08:44:46 +0100
From: "J.H.M. Dassen (Ray)" <[EMAIL PROTECTED]>
To: [EMA
Tom Lane wrote:
>
> Your last commit seems to have broken timestamp, interval, reltime,
> and horology regress tests on HPUX. Minus signs are showing up in
> a lot of unexpected-looking places...
> Is this now the intended behavior?
Uh, no. Believe it or not, I had just noticed this myself, and
Your last commit seems to have broken timestamp, interval, reltime,
and horology regress tests on HPUX. Minus signs are showing up in
a lot of unexpected-looking places, eg
*** ./expected/timestamp.outSat Nov 25 11:05:59 2000
--- ./results/timestamp.out Thu Jan 18 01:28:28 2001
*
To answer your question, wouldn't numeric(30,0) be the correct?
-alex
On Thu, 18 Jan 2001, The Hermit Hacker wrote:
>
> hrrmm ... ignore this ... I'm suspecting that what I did was copied in
> sum() data from an old table that had bytes declared as int4, without
> casting it to int8 before stor
On Thu, 18 Jan 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > if anyone is interested, here is one days worth of http traffic for the
> > main PostgreSQL.Org server ... this doesn't include the traffic that the
> > mirror sites absorb:
>
> > 1160643846 / ( 1024 * 1024 * 1024 )
> > 1.08gig
The Hermit Hacker wrote:
> if anyone is interested, here is one days worth of http traffic for the
> main PostgreSQL.Org server ... this doesn't include the traffic that the
> mirror sites absorb:
> 1160643846 / ( 1024 * 1024 * 1024 )
> 1.08gig
Not a bad day.
I've seen 100MB per day out of my
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I'm logging traffic to a database, so that I can do analysis on usage and
> whatnot, and I need something bigger then int8 :(
Those "maxbytes" values shure look like they're only int4. How are
you calculating 'em, exactly?
hrrmm ... ignore this ... I'm suspecting that what I did was copied in
sum() data from an old table that had bytes declared as int4, without
casting it to int8 before storing it to the new table ...
if anyone is interested, here is one days worth of http traffic for the
main PostgreSQL.Org serve
I'm logging traffic to a database, so that I can do analysis on usage and
whatnot, and I need something bigger then int8 :(
/tmp/psql.edit.70.79087: 6 lines, 222 characters.
ip | maxbytes | port |runtime
---+-+--+
216.12
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> I object. The code displays oids and tablenames or relnames. Oid is just
> the initial, default filename for tables, and may change to something other
> than the oid. Currently, the reindex code is the only place that could change
> the relfilenode
FYI, if you would like to build 7.1 with the UTF-8 <--> other
encodings capability, you need to configure --enable-multibyte AND
--enable-unicode-conversion, and that would add a 1MB conversion table
linked to the backend.
--
Tatsuo Ishii
> On Wed, Jan 17, 2001 at 01:40:58AM +0100, Rehak Tamas wr
[EMAIL PROTECTED] writes:
> configure:4207: checking for inflate in -lz
> configure:4226: gcc -o conftest conftest.c -lz -lgen -lnsl -lsocket -ldl -lm
>-lreadline -ltermcap -lcurses 1>&5
> configure:4660: checking for crypt.h
> This doesn't tell me much. But I modified configure to exit r
> I object. The code displays oids and tablenames or relnames. Oid is just
> the initial, default filename for tables, and may change to something other
> than the oid. Currently, the reindex code is the only place that could change
> the relfilenode without changing the oid, but I think there may
>I'll take care of fixing what I broke, but does anyone have suggestions
>for good names for the two concepts? The best I could come up with
>offhand is BEGIN/END_CRIT_SECTION and BEGIN/END_SUPER_CRIT_SECTION,
>but I'm not pleased with that... Ideas?
Let CRITICAL be critical. If the other sect
On Wed, Jan 17, 2001 at 05:49:36PM -0500, Bruce Momjian wrote:
> Wow, this looks great, and it worked the first time too. I will commit
> if no one makes objects.
>
I object. The code displays oids and tablenames or relnames. Oid is just
the initial, default filename for tables, and may change
Wow, this looks great, and it worked the first time too. I will commit
if no one makes objects.
> > > > Is there a way to relate this to the names of the databases? Why the
> > > > change? Or am I missing something key here..
> > >
> > > See the thread on the renaming in the archives. In sho
On Wednesday 17 January 2001 02:53, Alessio Bragadini wrote:
> Hunter Hillegas wrote:
> > I don't think they're moving the actual Slashdot site to PostgreSQL...
>
> So do I.
>
> > I think other sites based on Slashcode wanted to be able to use
> > PostgreSQL though...
>
> That's what I will do as
Cursors are not supported in PL/pgSQL. I don't see a TODO item to fix
this.
Fixing the syntax to support cursors is easy. The problem then is
that PL/pgSQL uses SPI, and SPI does not support cursors. In spi.c
there is a bit of code for cursor support, with the comment
/* Don't work cur
"Robert E. Bruccoleri" wrote:
>
> >
> > what are the cost estimates when you run explain with seqscan disabled ?
> > do => SET ENABLE_SEQSCAN TO OFF;
> > see:
> >
>(http://www.postgresql.org/devel-corner/docs/admin/runtime-config.htm#RUNTIME-CONFIG-OPTIMIZER)
>
> Here's the result from EXPLAIN:
On Wed, Jan 17, 2001 at 01:40:58AM +0100, Rehak Tamas wrote:
>
> > 3) upgrade to 7.1 that has the capability to do an automatic
> >conversion between UTF-8 and ISO-8859-1.
>
> i like to use deb packages and to use 7.1 i would have to upgrade
> to woody (or even sid)...
Not true. There are D
Greetings, and thanks for your reply!
Tom Lane <[EMAIL PROTECTED]> writes:
> Camm Maguire <[EMAIL PROTECTED]> writes:
> > Greetings! We have a script updating our database with thousands of
> > entries on a daily basis. To speed up processing, we drop a
> > consistency check trigger before the
I am trying to store a binary file with Visual Basic 6.0 and ADO and I
use the oid data type. The same code with Oracle and the clob type works
but with PostgreSQL I receive an error saying "Multiple Step Operation
generated errors. Check each status value.".
I am using the ODBC drivers and I a
> > I have been studying DeadLockCheck for most of a day now,
> > and I doubt that this is the only bug lurking in it.
> > I think that we really ought to throw it away and start
> > over, because it doesn't look to me at all like a standard
> > deadlock-detection algorithm. The standard way of
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Because I think turning an elog(ERROR) into a system-wide crash is
>> not a good idea ;-). If you are correct that this behavior
>> is necessary for WAL-related critical sections, then indeed we need
>> two kinds of critical sections, one that just
Dear Hannu,
>
> "Robert E. Bruccoleri" wrote:
> >
> > Dear Hannu,
> > >
> > > "Robert E. Bruccoleri" wrote:
> > > >
> > > > explain select count(*) from comparisons_4 where code = 80003;
> > > > NOTICE: QUERY PLAN:
> > > >
> > > > Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> > > > ->
> Because I think turning an elog(ERROR) into a system-wide crash is
> not a good idea ;-). If you are correct that this behavior
> is necessary for WAL-related critical sections, then indeed we need
> two kinds of critical sections, one that just holds off cancel/die
> response and one that tur
Re
On Tue, 16 Jan 2001, Tatsuo Ishii wrote:
> The encoding of your databases are all UNICODE. So you need to input
> data as UTF-8 in this case. I guess you are trying to input ISO-8859-1
> encoded data that is the source of the problem. Here are possible
> solutions:
> 1) input data as UTF-8
:)
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> It's very easy to don't notice ERROR - it's just transaction
> abort and transaction abort is normal thing, - but errors inside
> critical sections are *unexpected* things which mean that something
> totally wrong in code.
Okay. That means we do nee
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 16 January 2001 16:50
> To: Dave Page
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: [HACKERS] ODBC Driver int8 Patch
>
>
> As I remember, the problem is that this makes us match the
> ODBC v2 spec,
> but then we
Zeugswetter Andreas SB writes:
> > I do not have the original thread where Andreas describes the behavior
> > of mktime() on his machine. Andreas, can you suggest a simple configure
> > test to be used?
>
> #include
> int main()
> {
> struct tm tt, *tm=&tt;
> int i = -5000;
> tm
> > > The correct thing to do instead of the #if defined (_AIX) would be to use
> > > something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
> > ...Andreas, can you suggest a simple configure
> > test to be used?
> #include
> int main()
> {
> struct tm tt, *tm=&tt;
> int
"Robert E. Bruccoleri" wrote:
>
> Dear Hannu,
> >
> > "Robert E. Bruccoleri" wrote:
> > >
> > > explain select count(*) from comparisons_4 where code = 80003;
> > > NOTICE: QUERY PLAN:
> > >
> > > Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> > > -> Seq Scan on comparisons_4 (cost=0.
> > The correct thing to do instead of the #if defined (_AIX) would be to use
> > something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
> > Thomas, are you volunteering ?
>
> Actually, I can volunteer to be supportive of your efforts ;) I'm
> traveling at the moment, and don't
Camm Maguire <[EMAIL PROTECTED]> writes:
> Greetings! We have a script updating our database with thousands of
> entries on a daily basis. To speed up processing, we drop a
> consistency check trigger before the update and recreate it
> afterwards. Occasionally, we get the following, even thoug
Dear Hannu,
>
> "Robert E. Bruccoleri" wrote:
> >
> > explain select count(*) from comparisons_4 where code = 80003;
> > NOTICE: QUERY PLAN:
> >
> > Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> > -> Seq Scan on comparisons_4 (cost=0.00..15640.81 rows=7391 width=0)
> >
> > EXPLAIN
"Robert E. Bruccoleri" wrote:
>
> explain select count(*) from comparisons_4 where code = 80003;
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> -> Seq Scan on comparisons_4 (cost=0.00..15640.81 rows=7391 width=0)
>
> EXPLAIN
What is the type of field "code
> The correct thing to do instead of the #if defined (_AIX) would be to use
> something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
> Thomas, are you volunteering ?
Actually, I can volunteer to be supportive of your efforts ;) I'm
traveling at the moment, and don't have the orig
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> More importantly, PostgreSQL 6.5.3 works very, very well without
> VACUUM'ing.
>>
>> 6.5 effectively assumes that "foo = constant" will select exactly one
>> row, if it has no statistics to prove otherwise.
> I thought we had agreed upon a de
Greetings! We have a script updating our database with thousands of
entries on a daily basis. To speed up processing, we drop a
consistency check trigger before the update and recreate it
afterwards. Occasionally, we get the following, even though the
database has no other live connections, an
Alex Pilosov wrote:
>
> 3) index namespace should be constricted to the table on which it is
> indexed, since no commands to my knowledge manipulate the index without
> also specifying the table.
How about DROP INDEX ... ?
I'm not sure if this is standard SQL, maybe we should have
ALTER TABLE
Hi,
after getting GiST works we're trying to use RD-Tree in
our fulltext search application. We have universe of lexems
(words in dictionaries) which is rather large, so
we need some compression to effectively use RD-Tree.
When we did index support for int arrays we compressed
set by range sets b
> > > > > Yes, the annoyance is, that localtime works for dates before 1970
> > > > > but mktime doesn't. Best would probably be to assume no DST before
> > > > > 1970 on AIX and IRIX.
> > > >
> > > > That seems like a reasonable answer to me, especially since we have
> > > > other platforms tha
> > > > Yes, the annoyance is, that localtime works for dates before 1970
> > > > but mktime doesn't. Best would probably be to assume no DST before
> > > > 1970 on AIX and IRIX.
> > >
> > > That seems like a reasonable answer to me, especially since we have
> > > other platforms that behave tha
> > More importantly, PostgreSQL 6.5.3 works very, very well without
> > VACUUM'ing.
>
> 6.5 effectively assumes that "foo = constant" will select exactly one
> row, if it has no statistics to prove otherwise.
I thought we had agreed upon a default that would still use
the index in the above ca
> > > Yes, the annoyance is, that localtime works for dates before 1970
> > > but mktime doesn't. Best would probably be to assume no DST before
> > > 1970 on AIX and IRIX.
> >
> > That seems like a reasonable answer to me, especially since we have
> > other platforms that behave that way. How
46 matches
Mail list logo
