I've been working to make PostgreSQL run on SunOS4 (again).
So far I have found following issues:
o c.h 's sunos4 part should not include varargs.h. (Tom has already
fixed it) Instead, stdlib.h and stdarg.h should be included.
o no RAND_MAX or EXIT_FAILURE found. I simply added them to c.h.
Justin Clift wrote:
>
> I was just thinking that perhaps as part of the "beta" release process
> it would be worthwhile saying "New beta about to be released" (or
> similar) and then have the appropriate people for each platform/OS do a
> compile against the up-to-the-minute CVS and give a yes/no
>> This is what I got when tried to run mbregress.sh, what am I missing?
>>
>> destroydb: not found
Hm. destroydb was renamed to dropdb a release or two back, but it seems
mbregress.sh hasn't gotten the word yet.
>> /usr/local/pgsql/bin/pg_encoding: not found
This is a little more troubling.
> >> This is what I got when tried to run mbregress.sh, what am I missing?
> >>
> >> destroydb: not found
>
> Hm. destroydb was renamed to dropdb a release or two back, but it seems
> mbregress.sh hasn't gotten the word yet.
Good point. I didn't realize it. Will fix.
--
Tatsuo Ishii
From: "Jeff Lu" <[EMAIL PROTECTED]>
Subject: RE: Multibyte examples
Date: Tue, 20 Mar 2001 22:17:39 -0500
Message-ID: <[EMAIL PROTECTED]>
> Please excuse my ignorance in PostgreSQL for I'm new to this.
>
> This is what I got when tried to run mbregress.sh, what am I missing?
>
> destroydb: not
I Inoue wrote:
>
> Tom Lane wrote:
> >
> > > platform) i686-pc-linux-gnu, compiled by GCC egcs-2.91.60(turbolinux 4.2)
> > > min delay) 10msec according to your test program.
> > > -B) 64 (all other settings are default)
> >
> > Thanks. Could I trouble you to run it again with a larger -B, say
>
Tom Lane wrote:
>
> > platform) i686-pc-linux-gnu, compiled by GCC egcs-2.91.60(turbolinux 4.2)
> > min delay) 10msec according to your test program.
> > -B) 64 (all other settings are default)
>
> Thanks. Could I trouble you to run it again with a larger -B, say
> 1024 or 2048? What I've foun
From: "Jeff Lu" <[EMAIL PROTECTED]>
Subject: Multibyte examples
Date: Tue, 20 Mar 2001 12:38:26 -0500
Message-ID: <[EMAIL PROTECTED]>
> Tatsuo Ishii
>
> I've finally got the envirnoment set up to work with PostgreSQL, cygwin on
> NT
>
> Couldn't the regression test to run.
>
> When tried
> % m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we put special information into the first page of each heap file? I
> thought we used to, but I don't see that anymore.
You're thinking of indexes, perhaps? I don't recall ever seeing any
sign of a header page on heap files.
I was just thinking that perhaps as part of the "beta" release process
it would be worthwhile saying "New beta about to be released" (or
similar) and then have the appropriate people for each platform/OS do a
compile against the up-to-the-minute CVS and give a yes/no for each of
their platforms.
As well as Linux I run Solaris 8 SPARC (32-bit not 64), Solaris 7 SPARC
(SMP, 32-bit not 64), Solaris 7 Intel (both SMP and uni-processor) and
Solaris 8 Intel (both SMP and uni-processor).
I can be counted on to do testing of these as required in about 2 weeks
from now, after I get a new permanen
Do we put special information into the first page of each heap file? I
thought we used to, but I don't see that anymore.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe
Hi all
I develop in Visual FoxPro and I need to connect a client of Visual FoxPro
with a database PostgreSQL of a Server Linux
can somebody help me?
I don't know English a lot so they excuse me if I write bad
Thank's
Giuliano wrote:
>
> Hi all
> I develop in Visual FoxPro and I need to connect a client of Visual FoxPro
> with a database PostgreSQL of a Server Linux
> can somebody help me?
Use the ODBC driver. You can get it from
ftp://www.postgresql.org/pub/odbc/latest/
And make sure your postgres runs wit
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> Hmm, you mean you set up a separate test database for each pgbench
> >> "client", but all under the same postmaster?
>
> > Yes. Different database is to make the conflict as less as possible.
> > The conflict among backends is a
At 22:29 20/02/01 +0100, Peter Eisentraut wrote:
>Tom Lane writes:
>> And we frequently see questions from users about how they can display
>> fewer digits than the system wants to give them --- or, more
>> generally, format the output in some special form.
>
>to_char() should serve those people.
At 15:48 20/02/01 -0500, Tom Lane wrote:
>
>The existing default of FLT_DIG or DBL_DIG digits seems like a good
>general-purpose policy, but it doesn't meet all needs. For pg_dump,
>we clearly would like to promise exact dump and restore. On the
>other side, the geometry regress tests would like
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> Hmm, you mean you set up a separate test database for each pgbench
>> "client", but all under the same postmaster?
> Yes. Different database is to make the conflict as less as possible.
> The conflict among backends is a greatest enemy of CommitDelay
> I can find no use of LP_DELETE as defined as a flag in storage/itemid.h.
> A few places test it, but no one sets it.
>
> Can anyone else? Can I remove it in 7.2?
Never mind. It is used by work Vadim is doing:
---
*
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I changed pgbench so that different connection connects
> > to the different database and got the following results.
>
> Hmm, you mean you set up a separate test database for
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Thanks for killing the old versions. Now what do we do re PHP
> > with releases 4.0.4pl1 and earlier which now won't compile against
> > 7.1beta5 and later?
>
> > I think we need to do SOMETHING
>
> Frankly, if that's the biggest 7.0-to-7.1
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> And we frequently see questions from users about how they can display
>> fewer digits than the system wants to give them --- or, more
>> generally, format the output in some special form.
> to_char() should serve those people.
On
* Larry Rosenman <[EMAIL PROTECTED]> [010219 15:55]:
> * Larry Rosenman <[EMAIL PROTECTED]> [010219 15:45]:
> > * Tom Lane <[EMAIL PROTECTED]> [010219 15:43]:
> > > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > > I still think we need a dummy postgres.h in $(destdir)/include to
> > > > catch ot
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Thanks for killing the old versions. Now what do we do re PHP
> with releases 4.0.4pl1 and earlier which now won't compile against
> 7.1beta5 and later?
> I think we need to do SOMETHING
Frankly, if that's the biggest 7.0-to-7.1 compatibility p
Tom Lane writes:
> And we frequently see questions from users about how they can display
> fewer digits than the system wants to give them --- or, more
> generally, format the output in some special form.
to_char() should serve those people.
--
Peter Eisentraut [EMAIL PROTECTED] htt
> I think the idea of making a user-settable format string is a good one.
> I'm just afraid of the idea of trying to shoehorn in a solution at the
> last minute; if we do, we may find it's not quite right and then have
> a backwards-compatibility problem with fixing it. Besides, we are in
> "no n
I can find no use of LP_DELETE as defined as a flag in storage/itemid.h.
A few places test it, but no one sets it.
Can anyone else? Can I remove it in 7.2?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life
>> Would there be any value in setting up a project on sourceforge to
>> make use of their compile farm? I know that it doesn't cover all
>> platforms, but it would perhaps be a start to mechanical compile and
>> regression testing.
> I haven't looked at the platforms available in the compile fa
Pete Forman <[EMAIL PROTECTED]> writes:
> Please remind me what we are trying to do.
The real point is that we need to serve several different purposes
that aren't necessarily fully compatible.
The existing default of FLT_DIG or DBL_DIG digits seems like a good
general-purpose policy, but it doe
> > Anyway, your proposal is just fine since we haven't decoupled these
> > things farther back in the server. But eventually we should hope to have
> > SQL_ASCII and other character sets enforced in context.
>
> Now I'm confused. Are you saying that we *should* treat identifier case
> under AS
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Why not add CFLAGS=+02 to the hpux template?
Tested and done.
> Also, it should work now to build with any random combination of C and C++
> compilers, so maybe try that and remove that point.
You're right, that works now. FAQ_HPUX updated. Thank
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> Now I'm confused. Are you saying that we *should* treat identifier case
>> under ASCII rules only? That seems like a step backwards to me, but
>> then I don't use any non-US locale myself...
> I think we need to treat anything that is not q
Tom Lane writes:
> How hard would it be to make the --with-includes -I directives appear
> after our own?
Not hard, but tedious.
> The same problem arises for --with-libs, btw.
Not tedious, but hard.
I'll look into it.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
* Thomas Lockhart <[EMAIL PROTECTED]> [010220 10:51]:
> > Would there be any value in setting up a project on sourceforge to
> > make use of their compile farm? I know that it doesn't cover all
> > platforms, but it would perhaps be a start to mechanical compile and
> > regression testing.
>
> I
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Anyway, your proposal is just fine since we haven't decoupled these
> things farther back in the server. But eventually we should hope to have
> SQL_ASCII and other character sets enforced in context.
Now I'm confused. Are you saying that we *should*
> Would there be any value in setting up a project on sourceforge to
> make use of their compile farm? I know that it doesn't cover all
> platforms, but it would perhaps be a start to mechanical compile and
> regression testing.
I haven't looked at the platforms available in the compile farm
rec
Merhaba Sezai!
> I am starting to think that the only real solution is a special case
> for Turkish users. Perhaps use tolower() normally but have a compile-
> time option to use a non-locale-aware method:
istm that this illustrates the tip of the locale iceberg as we think
about moving to a mo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Why not add CFLAGS=+02 to the hpux template?
Hmm... now that you ask, probably no good reason.
> Also, it should work now to build with any random combination of C and C++
> compilers, so maybe try that and remove that point.
OK, I will. That defi
Title: RE: [HACKERS] beta5 ...
Would there be any value in setting up a project on sourceforge to make use of their compile farm? I know that it doesn't cover all platforms, but it would perhaps be a start to mechanical compile and regression testing.
Just a thought...
MikeA
-Ori
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I changed pgbench so that different connection connects
> to the different database and got the following results.
Hmm, you mean you set up a separate test database for each pgbench
"client", but all under the same postmaster?
> The results of
> p
Why not add CFLAGS=+02 to the hpux template?
Also, it should work now to build with any random combination of C and C++
compilers, so maybe try that and remove that point.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
>> As a matter of curiosity, is each beta compiled and then regression
>> tested against *every* one of the known "supported" platforms before
>> release?
Who are you expecting to do that, exactly?
One of the differences between Postgres and a proprietary commercial
database is that there is no
Sezai YILMAZ <[EMAIL PROTECTED]> writes:
> You are right. What about this one?
> setlocale(LC_ALL, "C");
> for(i = 0; yytext[i]; i++)
> if (isascii((unsigned char)yytext[i]) &&
> isupper(yytext[i]))
Tom Lane writes:
> I notice that if the platform's template doesn't set CFLAGS, then
> configure will give you -g in CFLAGS whether you ask for it or not
> (courtesy of AC_PROG_CC). The --enable-debug configure switch thus does
> not function as advertised. If we are going to say that --enable-
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
>>
>> I think I like RESULT_OID because the standard uses RESULT.
> RESULT* is used for SELECT statements, but RES
Bruce Momjian writes:
> > I just committed changes that make it RESULT_OID, but if you like
> > INSERTED_OID better, we could change it...
>
> I think I like RESULT_OID because the standard uses RESULT.
RESULT* is used for SELECT statements, but RESULT_OID is for INSERT
commands. It sounds a bi
> As a matter of curiosity, is each beta compiled and then regression
> tested against *every* one of the known "supported" platforms before
> release?
No. But the changes from beta to beta are usually done with platform
compatibility in mind, and we try to stay away from introducing
platform-spe
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I've been suspicious if pgbench is an (unique)
> > appropiriate test case for evaluaing commit_delay.
>
> Of course it isn't. Never trust only one benchmark.
>
> I've asked the Great Bridge folks to run their TPC-C benchmark with
Tom Lane writes:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The defaults
> >> would be "%.7g" and "%.17g" (or thereabouts, not sure what number of
> >> digits we are currently using).
>
> > Wouldn't changing current '%.6g','%.15g'(on many platforms)
> > cause the
Hi all,
As a matter of curiosity, is each beta compiled and then regression
tested against *every* one of the known "supported" platforms before
release?
Like, as an official "checklist" type step?
Regards and best wishes,
Justin Clift
Database Administrator
50 matches
Mail list logo
