Tom Lane writes:
> The bit test diffs seem to indicate that bit_cmp is messed up. That
> depends on memcmp. I seem to recall something about memcmp not being
> 8-bit-clean on SunOS ... does that ring a bell with anyone?
Sure enough:
- Macro: AC_FUNC_MEMCMP
If the `memcmp' function is no
Thomas Lockhart writes:
> Peter, what would you suggest for schedule?
We freeze everything now and move on with our lives. There's always a
next release.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)
Tom Lane writes:
> > and yet another run (and different results):
>
> > =
> > 1 of 76 tests failed, 1 failed test(s) ignored.
> > =
>
> That's just ye olde random "random" failure ...
Actually, this
Tatsuo Ishii writes:
> I have a plan to translate 7.1 docs into Japanases
Btw...
One thing I am thinking about doing for the 7.2 cycle is set up the
doc/src/ directory in a way to keep translations in tree. It would
probably look something like:
doc/src/
sgml/ -- original (implicitl
Tom Lane writes:
> Okay. I've committed a configure check that tests to see whether a
> macro defined as above compiles, and if so it will be used (if we are
> using "long long" for int64). Hopefully the check will prevent breakage
> on machines where LL is not appropriate.
I don't see what th
Thomas Lockhart writes:
> I put in contacts.sgml a *long* time ago, thinking that something like
> it should be in the docs. But it was not complete enough to consider
> including at the time (now that I look, it only has my name ;), so it
> was only a placeholder for the future.
The "Resources"
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't see what this configure check buys us, since it does not check for
> anything that's ever been reported not working. Do you think there are
> platforms that have 'long long int' but no 'LL' suffix? That seems more
> than unlikely.
Well, I d
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
> =
> 1 of 76 tests failed, 1 failed test(s) ignored.
> =
>>
>> That's just ye olde random "random" failure ...
> Actually, this is one
I'll take the deafening silence as a NO?
LER
* Larry Rosenman <[EMAIL PROTECTED]> [010323 16:59]:
> Can I get a go/nogo decision on whether these two functions can be #if'd
> out for 7.1?
>
> Thanks.
>
> LER
>
>
> >> Original Message <<
>
> On 3/22/01, 4:02
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> All functions are documented (for appropriate values of "all") in the
> User's Guide, chapter 4. There was probably once the idea of setting up a
> reference page set for the functions, but I don't know if this is
> particularly better than what we h
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I'll take the deafening silence as a NO?
I was (a) waiting to see what Peter thought about it, and (b) wondering
whether you'd actually tested to see that the built ODBC driver does
something useful. I'm not eager to risk a post-RC1 change that could
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> The bit test diffs seem to indicate that bit_cmp is messed up. That
>> depends on memcmp. I seem to recall something about memcmp not being
>> 8-bit-clean on SunOS ... does that ring a bell with anyone?
> Sure enough:
> - Macro
Tom Lane <[EMAIL PROTECTED]> writes:
> If you look closely, the configure test is not simply checking whether
> LL is accepted, it is checking whether we can construct an acceptable
> constant by macroized token-pasting. That's a slightly larger
> assumption, but it's the one the code must actua
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> A safe way to construct a long long constant is to do it using an
> expression:
> uint64) 0xdeadbeef) << 32) | (uint64) 0xfeedface)
> It's awkward, obviously, but it works with any compiler.
An interesting example. That will work as intended
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > A safe way to construct a long long constant is to do it using an
> > expression:
> > uint64) 0xdeadbeef) << 32) | (uint64) 0xfeedface)
> > It's awkward, obviously, but it works with any compiler.
>
>
I did a cvs pull of the head on 3/24/01 and used Sun's cc
compiler 5.0 (with all patches as of 2/1/01) to build.
I ran into a problem building pg_backup_null.c rev 1.5.
The following patch lets me build:
Index: src/bin/pg_dump/pg_backup_null.c
===
I recently got sent a survey to fill out that is meant to compare various
Object databases ... there are ~20 sections to this thing, asking
questions ranging from General Architecture to interactions with External
DBMSs ... and *alot* of questions that I've no experience in, and,
therefore, no an
Steve Nicolai <[EMAIL PROTECTED]> writes:
> diff -u -r1.5 pg_backup_null.c
> --- src/bin/pg_dump/pg_backup_null.c2001/03/22 04:00:13 1.5
> +++ src/bin/pg_dump/pg_backup_null.c2001/03/24 22:00:07
> @@ -98,7 +98,7 @@
> static void
> _PrintTocData(ArchiveHandle *AH, TocEntry *te, Restor
Tom Lane writes:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > I'll take the deafening silence as a NO?
>
> I was (a) waiting to see what Peter thought about it,
Don't ask me, I don't know what this does...
> and (b) wondering
> whether you'd actually tested to see that the built ODBC driver
* Peter Eisentraut <[EMAIL PROTECTED]> [010324 17:35]:
> Tom Lane writes:
>
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > I'll take the deafening silence as a NO?
> >
> > I was (a) waiting to see what Peter thought about it,
>
> Don't ask me, I don't know what this does...
>
> > and (b)
Greetings,
I have been following along with the thread and would just like to say a
few paragraphs.
Can't the contributors themselves run pgindent on the files which they
have changed _just_ before creating the patch which is to be contributed?
Thus, patching a "pure" pgindented file from
Continuing on my quest to get 7.1 to build on Solaris 8 with
Sun's cc 5.0, I found an alignment problem in
backend/access/heap/tuptoaster.c
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
=>[1] toast_save_datum(rel = 0x5fb4c8, mainoid = 18714U, attno = 7, value =
6548664U), line 816 in "tupto
Christopher Sawtell <[EMAIL PROTECTED]> writes:
> Can't the contributors themselves run pgindent on the files which they
> have changed _just_ before creating the patch which is to be contributed?
That would require everyone to have a working copy of BSD indent (gnu
indent does not behave the s
Steve Nicolai <[EMAIL PROTECTED]> writes:
> Continuing on my quest to get 7.1 to build on Solaris 8 with
> Sun's cc 5.0, I found an alignment problem in
> backend/access/heap/tuptoaster.c
Good catch. I fixed a couple similar problems (assuming that a local
"char buffer[N]" object would be aligne
On Sat, Mar 24, 2001 at 02:05:05PM -0800, Ian Lance Taylor wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > A safe way to construct a long long constant is to do it using an
> > > expression:
> > > uint64) 0xdeadbeef) << 32) | (uint64) 0x
> Tatsuo Ishii writes:
>
> > I have a plan to translate 7.1 docs into Japanases
>
> Btw...
>
> One thing I am thinking about doing for the 7.2 cycle is set up the
> doc/src/ directory in a way to keep translations in tree. It would
> probably look something like:
>
> doc/src/
> sgml/
On Sun, 25 Mar 2001, Tatsuo Ishii wrote:
> > Tatsuo Ishii writes:
> >
> > > I have a plan to translate 7.1 docs into Japanases
> >
> > Btw...
> >
> > One thing I am thinking about doing for the 7.2 cycle is set up the
> > doc/src/ directory in a way to keep translations in tree. It would
> > pro
Peter Eisentraut wrote:
> Tatsuo Ishii writes:
>
> > I have a plan to translate 7.1 docs into Japanases
>
> Btw...
>
> One thing I am thinking about doing for the 7.2 cycle is set up the
> doc/src/ directory in a way to keep translations in tree. It would
> probably look something like:
>
> doc/
[Cced: to hackers list]
Can you turn off --enable-locale or set locale to C and try again? I
guess upper() does bad thing in that it thinks the letter is Polish
but actually it is unicode(UTF-8).
--
Tatsuo Ishii
> I have encountered some problems while trying to create a database that
> would
29 matches
Mail list logo
