Am Freitag, 13. April 2001 23:16 schrieben Sie:
> Tom Lane wrote:
> > A more significant point is that you have presented no evidence to back
> > up your claim that this would be materially faster than the existing
> > type. I doubt that the extra pallocs are all that expensive. (I think
> > it'
Hi,
Sorry, per OOC...
Somebody could tell me where I can find documentation online about SQL2
and SQL3 (especially the last).
This the SQL3 approved finally?
That match is between SQL92,SQL96,SQL99 and the SQL2 and SQL3?
Thanks,
Sergio
---(end of broadcast)--
On Fri, Apr 13, 2001 at 03:12:57AM -0400, Tom Lane wrote:
> I have some interest in proposals to switch to a better parser-generator
> tool than yacc ...
There are tools to produce efficient top-down parsers as well. Those
doing such parsers "by hand" may be interested in looking at PCCTS
(http:
Folks,
By now, I imagine a number of people have seen the piece on the
Computer Reseller News website about Great Bridge and PostgreSQL.
While I think we're all happy to see the increased visibility for
PostgreSQL (especially as compared to the Oracles of the world),
it's fair to say the article
So, to sum up ... the article did a good job of representing Great Bridge,
did a great injustice (a slap in the face, so to say) to the PostgreSQL
community as a whole, so Great Bridge has no intention of correcting the
situation?
Just to clarify your position, of course ...
On Sun, 15 Apr 2001
On Sat, 14 Apr 2001, Nathan Myers wrote:
> This is probably a good time to point out that this is the _worst_
> _possible_ response to erroneous reportage. The perception by readers
> will not be that the reporter failed, but that PostgreSQL advocates
> are rabid weasels who don't appreciate fav
Bruce Momjian wrote:
>
> Do we need to start thinking about an RPM mailing list? Seems there is
> lots of traffic.
IIRC, this question was asked about 6 months ago, and the answer was RPM
should be discussed on PostgreSQL-Ports.
On the other hand, it seems in practice most people are unaware
At 01:08 15/04/01 -0400, Tom Lane wrote:
>
>SFUNC1/STYPE1/INITCOND1 in 7.0 equate to SFUNC/STYPE/INITCOND in 7.1.
>There is no 7.1 equivalent to 7.0's SFUNC2/STYPE2/INITCOND2
It now outputs a warning to stderr as well as the dump file.
> --- those
>have to be saved/restored separately if you ar
To top it all off, their comments are broken -- I submitted mine and it
displays Marc's again (until you click on the link of course)..
*sigh* they must be using MySQL. :-)
-Mitch
- Original Message -
From: "The Hermit Hacker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, Ap
The "Current Release Docs" on the PostgreSQL website still look 7.0.Xish..
Just an FYI...
-Mitch
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
> *sigh* they must be using MySQL. :-)
*rofl*
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
>
> Here's my response to the inaccurate article cmp produced. After
> chatting with Marc I decided to post it myself.
>
> Since I know Ned reads this list, I formally request that he also
> insists PUBLICALLY that cmp correct their inaccuracies. I'm rather
> disappointed (for lack of a more d
>
> Here's my response to the inaccurate article cmp produced. After
> chatting with Marc I decided to post it myself.
>
> Since I know Ned reads this list, I formally request that he also
> insists PUBLICALLY that cmp correct their inaccuracies. I'm rather
> disappointed (for lack of a more d
> > It will be harder than the original mailings, but I urge each who
> > wrote to write again and apologize for attacking her.
>
> In a way, I think you are right .. I think the attack was aimed at the
> wrong ppl :( She obviously didn't get *any* of her information from ppl
> that belong *in*
Mario Weilguni wrote:
> I tested that on a similar configuration (P-III 450) and got the same
> results. When the addition is removed from the loop and replaced with a
> simple assignment, the total execution time goes down to ~6.5 seconds. That
> means that the modified numeric is nearly twice a
There was a discussion once about using 64 bit long long compiler support to
increase the size of the transaction ids to solve the wrap around problem. I
understand that there is a different solution for this now.
However, my question is: Are we to the point where int64's can be used in
mainstre
Mark Butler <[EMAIL PROTECTED]> writes:
> ... The correct numbers should be:
> Postgres PL/PGSQL original numeric:14.8 seconds
> Postgres PL/PGSQL modified numeric:14.0 seconds
> Postgres PL/PGSQL float8: 10.7 seconds
> GNU AWK:2.5 seconds
> Or
At 10:59 PM 14-04-2001 -0400, Lamar Owen wrote:
>http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
>
>Marc will be pleased to note that the PostgreSQL project came out of the
>FreeBSD project, and is Great Bridge's database. Gotta love
>journalistic license.
Reporter must
Bruce Momjian wrote:
> Not that it shouldn't be fixed. I just don't get worked up over it.
Well, in a way I regret bringing it to the attention of the community --
just in a small way.
But at the same time I realized that I was not the right one at that
time to craft a reply -- after all, I'm a
On Sun, Apr 15, 2001 at 11:44:48AM -0300, The Hermit Hacker wrote:
> On Sat, 14 Apr 2001, Nathan Myers wrote:
>
> > This is probably a good time to point out that this is the _worst_
> > _possible_ response to erroneous reportage. The perception by readers
> > will not be that the reporter faile
On Mon, 16 Apr 2001, Lincoln Yeoh wrote:
> Maybe you guys should get some Great Bridge marketing/PR person to handle
> stuff like this.
After reading Ned's comments I figured that's how it got that way in
the first place. But that's just speculation.
Vince.
--
>
> Here's my response to the inaccurate article cmp produced. After
> chatting with Marc I decided to post it myself.
>
> Since I know Ned reads this list, I formally request that he also
> insists PUBLICALLY that cmp correct their inaccuracies. I'm rather
> disappointed (for lack of a more d
the thing that pissed me off the most, and set me off, was the totally
blatant errors ... we've had other articles written, with a GB slant to
them, that didn't get my feathers in a ruffle ... the fact that they
*talked* with GB, got quotes from them and some of their partners, and
*still* got th
I wanted to comment on how we handled this article.
Seems the author did not understand the company/open-source
relationship. This is not a huge surprise. I have to explain it to my
friends and relatives all the time. Now, our way of dealing with users
who ask questions is to gently lead them
> You can tell people why they shouldn't feel a certain way, but
> preventing them from expressing their feelings is usually a bad thing,
> unless their expression is hurting other people. (Hurting my feelings
> is OK.)
>
> I usually sit back until everyone's cards/feelings are on the table, an
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> On Mon, 16 Apr 2001, Lincoln Yeoh wrote:
>> Maybe you guys should get some Great Bridge marketing/PR person to handle
>> stuff like this.
> After reading Ned's comments I figured that's how it got that way in
> the first place. But that's just specul
On Sun, Apr 15, 2001 at 10:05:46PM -0400, Vince Vielhaber wrote:
> On Mon, 16 Apr 2001, Lincoln Yeoh wrote:
>
> > Maybe you guys should get some Great Bridge marketing/PR person to handle
> > stuff like this.
>
> After reading Ned's comments I figured that's how it got that way in
> the first pl
OK, looks like we have a Tru64 problem with 7.1 too. Can you tell us
how to get a NAN value. Zero is not it. I see the following mentions
of NAN in the code. Does NAN exist in one of your /usr/include files?
include/port/qnx4.h:18:#ifndef NAN
include/port/
> OK, looks like we have a Tru64 problem with 7.1 too. Can you tell us
> how to get a NAN value. Zero is not it. I see the following mentions
> of NAN in the code. Does NAN exist in one of your /usr/include files?
We had at least three reports of successful compilation on Tru64 4.0[dg]
and 5
>What I would like to know is, if I have changed some ot the modules,
> how can I use GNU gdb to debug the modified codes?
You can run the backend directly from gdb:
$ gdb postgres
(set breakpoint)
> b
(tell gdb to begin)
> run -D
(enter query at prompt)
> select xyz from abc...
(
No, those don't do it. We need an actual NaN value. These are just
flags, I think.
> There are two things I found from fp_class.h, FP_SNAN (a signaling NaN),
> and FP_QNAN (a quiet NaN). Don't know which you want:
> alphapc.ourservers.net> grep FP_SNAN /usr/include/*
> /usr/include/fp_class
Mark Butler <[EMAIL PROTECTED]> writes:
> However, my question is: Are we to the point where int64's can be used in
> mainstream code yet, or are there supported platforms that this will not work
> with? And if not, when (if ever) will such capability be standardized?
I don't foresee ever being
32 matches
Mail list logo
