2005/12/4, Andrew Dunstan [EMAIL PROTECTED]:
Tom said:
Would it work to modify c.h so that it #include's libintl.h, then #undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive
2005/12/6, Nicolai Tufar [EMAIL PROTECTED]:
IIRC last time I tried this it didn't work too well ;-( I will have
another go. I think it's the best way to go.
Very well, I will try to put up a patch to implement it in a couple of days.
Oh boy, it is already fixed. Sorry folks, my error
are
printed by the server.
Kindest regards,
Nicolai Tufar
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On 6/17/05, Josh Berkus josh@agliodbs.com wrote:
Hey, Folks,
I need to find someone who's really interesed in working with DTrace. Sun
has offered to help put DTrace probes into PostgreSQL for advanced
profiling, but need to know where to probe. Anyone?
I'm afraid that I won't get
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
I have applied a modified version of your patch, attached.
I am so sorry, I sent untested patch again. Thank you very
much for patience in fixing it. The patch looks perfectly
fine and works under Solaris.
Resubmission of yesterday's patch so that it would
cont conflict with Bruce's cvs commit. Pleas apply.
Best regards,
Nicolai.
On Sat, 12 Mar 2005 01:58:15 +0200, Nicolai Tufar [EMAIL PROTECTED] wrote:
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The CVS-tip implementation is fundamentally broken and won't work even
for our internal uses. I've not wasted time complaining about it
because I thought we were going to replace it. If we can't find a
, 32-bit. Even for
a shared library it will probably be too much. Trio has a lot
of string handling functions which are probably not necessary.
Would you like me to try to remove everything unnecessary from
it or we will settle with the full version?
Regards,
Nicolai Tufar
implementation of snprintf.c and replace it with a very much
stripped down of Trio's one. I will work on it and try to get
a patch in one week's time. Thank you all for your patience.
Best regards,
Nicolai Tufar
--
Bruce Momjian| http://candle.pha.pa.us
pgman
, have you looked at Trio? If it is fine with you too,
I will strip it to the bare minimum needed for snprintf(), vsnprintf() and
printf() by Saturday.
Regards,
Nicolai Tufar
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ
On Fri, 11 Mar 2005 01:14:31 -0500, Tom Lane wrote:
Nicolai Tufar [EMAIL PROTECTED] writes:
Very well, I too, tend to think that importing some else's solution
is the way to go. Tom, have you looked at Trio?
I have not seen it ... but if it looks reasonable to you, have a go
implement?
Regards,
Nicolai Tufar
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Wed, 2 Mar 2005 09:24:32 +0100, Joerg Hessdoerfer
[EMAIL PROTECTED] wrote:
don't know if PG borrowed the code from here, but according to the manpage
FreeBSD 5.3 seems to have a quite complete implementation, see
On Tue, 1 Mar 2005 00:55:20 -0500 (EST), Bruce Momjian
My next guess
is that Win32 isn't handling va_arg(..., long long int) properly.
I am trying various combination of number and types
of parameters in my test program and everything prints fine.
When it comes to pg, it fails :(
I spent all day debugging it. Still have absolutely
no idea what could possibly go wrong. Does
anyone have a slightest clue what can it be and
why it manifests itself only on win32?
On Tue, 1 Mar 2005 09:29:07 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
Nicolai Tufar wrote
On Tue, 1 Mar 2005 15:38:58 -0500 (EST), [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Is there a reason why we don't use the snprintf that comes with the
various C compilers?
snprintf() is usually buried in OS libraries. We implement
our own snprintf to make things like this:
snprintf(buf,%2$s
On Tue, 1 Mar 2005 16:20:50 -0500 (EST), [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Well, here is a stupid question, do we even know which snprintf we are
using on Win32? May it be possible that we are using the MingW version
which may be broken?
Defenitely not. I checked it by placing
On Tue, 01 Mar 2005 17:45:31 -0500, Tom Lane Just out of curiosity,
do either HAVE_INT64 or HAVE_UINT64 get set
in pg_config.h?
pg_config.h is attached. What drew my attention is the
following declaration:
/* Define to 1 if `long long int' works and is 64 bits. */
#define
Linux and Solaris 10 x86 pass regression tests fine when I force the use of new
snprintf(). The problem should be win32 - specific. I will
investigate it throughly
tonight. Can someone experienced in win32 what can possibly be the problem?
Nick
On Sun, 27 Feb 2005 19:07:16 +0100, Magnus
a look at this? I am 90% sure it is an issue with
some configure definitions.
Best regards,
Nicolai
On Mon, 28 Feb 2005 19:58:15 +0200, Nicolai Tufar [EMAIL PROTECTED] wrote:
Regression test diff is attached.
It fails on the following tests:
int8
subselect
union
sequence
Neither Bruce's nor subsequent Tom's patch did not fix
the issue. The command used is:
make maintainer-clean ./configure make make install make check
It should have be fine to recompile the source code
completely. I attach the resulting config.log. May be it
will give a clue. Regression test
And while we are on it, I would like to submit minor
changes to make snprintf() vsnprintf() and printf()
functions in src/port/snprintf.c thread-safe.
Best regards,
Nicolai Tufar
Index: src/port/snprintf.c
===
RCS file: /projects
On Thu, 24 Feb 2005 22:18:11 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Didn't we do that already?
No :( I promised to do it a couple of weeks ago but could not get to do it.
Now with Magnus's help I finaly did it. The last patch should be fine.
regards, tom lane
On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote:
Applied.
Thanks a lot. The patch attached solves the tread
safety problem. Please review it before applying,
I am not sure I am doing the right thing
On Tue, 22 Feb 2005 19:57:15 +0100, Kurt Roeckx [EMAIL PROTECTED] wrote:
The
On Sun, 13 Feb 2005 19:06:34 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
Anyway, this is too large to put into 8.0, but I am attaching a patch
for 8.1 that has the proper configure tests to check if the C library
supports this behavior. If it does not, the build will use our
/backend/po/tr.po
src/bin/pg_dump/po/zh_CN.po
src/bin/pg_dump/po/tr.po
src/bin/psql/po/zh_CN.po
src/bin/psql/po/zh_TW.po
src/bin/psql/po/tr.po
src/bin/scripts/po/zh_CN.po
we need to fix snprintf.c before next release
Best regards,
Nicolai Tufar
*** ./src/port/snprintf.c.orig 2005-01-20 01:27
thing to do.
Could someone give a hint on where I need to place such a
definition.
Best regards,
Nicolai Tufar
*** ./src/port/snprintf.c.orig 2005-01-20 01:27:22.0 +0200
--- ./src/port/snprintf.c 2005-01-24 03:09:31.0 +0200
***
*** 57,62
--- 57,66
On Sun, 23 Jan 2005 21:43:17 -0800, Benjamin Arai [EMAIL PROTECTED] wrote:
What are the goals for 8.1?
Fix %n$ format string argument placement in
platforms that do not support it, like HP-UX, Win32
Best regards,
Nicolai
---(end of broadcast)---
platform too.
Best regards,
Nicolai Tufar
/*
* Copyright (c) 1983, 1995, 1996 Eric P. Allman
* Copyright (c) 1988, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted
with
my or with original snprintf.c.
Best regards,
Nicolai Tufar
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Sat, 22 Jan 2005 15:31:39 +0100, Peter Eisentraut [EMAIL PROTECTED] wrote:
Nicolai Tufar wrote:
1. I renamed snprintf() to pg_snprintf(), vsnprintf() to
pg_vsnprintf() and introduced pg_printf() that calls pg_vsnprintf().
This is not necessary. You will notice that we already have
and value,
call snprintf() and the combine the resulting string?
The first solution requires doing nasty manipulations
with va_list, the second will be slower because of
multiple calls to snprintf().
Which one is better?
Best regards,
Nicolai Tufar
regards, tom lane
there.
Comments?
Perfectly fine. Please go ahead.
--
Peter Eisentraut
Nicolai Tufar
Turkish Language Translation Team.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
of chamgne tonight to celebrate 8.0.
Peter Eisentraut
http://developer.postgresql.org/~petere/
Best regards,
Nicolai Tufar
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Alvaro Herrera wrote:
Maybe we should have a pgfoundry project where all translations were
kept, and from which the main CVS could be updated
semi-automatically. Then we wouldn't have Peter checking out and
committing all the time.
Peter Eisentraut wrote:
That sounds like a fine idea.
Sorry for such a late submission.
I just downloaded the latest postgresql-8.0.0-rc5-3.zip installer
for windows and it appears that Windows' printf() does not
support placeholder replacement as described in
http://developer.postgresql.org/docs/postgres/nls.html#AEN57284
I searched list archives
On Mon, 17 Jan 2005 16:17:33 -0300, Fx [EMAIL PROTECTED] wrote:
unix/win32 libc doesnt support $n variables..
What can we do then?
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
to implement this for 8.1 and
would be honoured if I get a chance to contribute.
regards, tom lane
Best regards,
Nicolai Tufar
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
, remove the offending code, clean up
CVS and shout from the rooftops about the hypocrisy of
IBM.
Hope it helps make up your mind,
Best regards,
Nicolai Tufar
P.S. But if filing date really is 2002 and there
is no prior art me may skip step 1.
---(end of broadcast
On Mon, 17 Jan 2005 14:02:14 -0800, Joshua D. Drake
[EMAIL PROTECTED] wrote:
IBM can NEVER sue customers for using infringing
code before first informing them of infringement and
giving reasonable time to upgrade to uninfringing
version.
I can see it now:
We won't sue you (customer) but
through PCT since a refusal in one country may
cause to patent to be refused in all countries.
Hope it helps,
Nicolai Tufar
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Tue, 07 Dec 2004 13:51:36 -0500, Tom Lane [EMAIL PROTECTED] wrote:
FWIW, I get clean regression test passes on a real z900 at Red Hat,
in both s390 and s390x (32- and 64-bit) modes. I'm not sure what that
means --- it could be that Red Hat Linux doesn't use the hardware
floating point, or
:04:43
Best regards,
Nicolai Tufar
---(end of broadcast)---
TIP 8: explain analyze is your friend
mainframes machines
produced by IBM a decade ago. They still can be bought on eBay for
something like $5,000. They can run Linux too.
Regards,
Nicolai Tufar
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
-Original Message-
From: Tom Lane
Did you try running the regression tests under tr_TR locale? It seems
a few bricks short of fine yet :-(
I run regression tests under tr_TR locale. To do this I hardcoded
Turkish locale in initdb in pg_regress.sh. Three tests failed, I
attached
Sorry for rising up old issue again but the problem still persists.
And database cluster is not being created with Turkish locale
If you have any doubts about how Turkish users will react to the fact
that both I and I WITH DOT will be treated as same character, rest
assured that this behavior is
-Original Message-
From: Dave Page [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 11:02 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [HACKERS] PITR Dead horse?
Of course, but I would argue that my claim that PostgreSQL is reliable
is backed up by the lack of
-Original Message-
From: Dave Page [mailto:[EMAIL PROTECTED]
My SQL2K servers give me far more sleepless nights than PostgreSQL
ever
did!
You bet! I totally agree with you.
Technicians like you, me and most people on this list
Already know that PostgreSQL is stable and reliable.
It is
I would like to join this effort too.
I was afraid that people at RedHat are already
halfway though and were to release their work
shortly. But it does not seem to be the case.
Regards,
Nicolai
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On
PostgreSQL does
not have it.
I am well versed in the internals of PITR features of a certain
leading enterprise-class database out there. And would like to
contribute (write code) to this effort as much as I can.
Best regards,
Nicolai Tufar
-Original Message-
From: [EMAIL PROTECTED
Tom Lane [EMAIL PROTECTED] wrote:
Nicolai Tufar [EMAIL PROTECTED] writes:
A possible compromise is to apply ASCII downcasing (same as in
keywords.c) for 7-bit-ASCII characters, and apply tolower() only
for character codes above 127. In other words
If we go this way why not make
Oops, forgot the patch :)
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Nicolai Tufar
Sent: Tuesday, February 03, 2004 9:31 PM
To: [EMAIL PROTECTED]
Cc: 'Tom Lane'; [EMAIL PROTECTED]
Subject: [HACKERS] Turkish Locale in Identifiers
but stored in pg_am* catalogue
tables. Could someone please explain -very briefly- what exactly is
happening when a sort is performed. A kind of stack trace: which
function
calls which one would be very appreciated.
Best regards,
Nicolai Tufar
---(end of broadcast
and
it is wrong! I will contact glibc team now.
Thanks a lot for help.
Regards,
Nicolai Tufar
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL
Tom Lane [EMAIL PROTECTED] wrote:
Nicolai Tufar [EMAIL PROTECTED] writes:
A possible compromise is to apply ASCII downcasing (same as in
keywords.c) for 7-bit-ASCII characters, and apply tolower() only
for character codes above 127. In other words
If we go this way why not make a special
in source code but could not, despite all my efforts. I would very
much appreciate if someone would point out what functions are
being called while sorting data for return for ORDER BY clause.
Thanks in advance,
Nicolai Tufar
---(end of broadcast
. Could you pleas
advise if the name I chose
is appropriate and whether there is a more appropriate
place to put declaration and initialization.
Best regards,
Nicolai Tufar Devrim Gunduz
trpatch.diff
Description: Binary data
---(end of broadcast
---
Nicolai Tufar wrote:
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert locale
names to lower-case. This causes errors if locale name contains
my wish:
* error codes. It's very interesting that nobody other wants it...
I do :-)
Me too. It is a must in my opinion..
Regards,
Nic.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert locale
names to lower-case. This causes errors if locale name contains
capital I and current olcale is Turkish. Some examples:
aaa=# \l
List of databases
- Original Message -
From: Hannu Krosing [EMAIL PROTECTED]
To: Nicolai Tufar [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, November 30, 2002 5:41 PM
Subject: Re: [HACKERS] Locale-dependent case conversion in {identifier}
[ ... ]
could it just be that we store
src/bin/pg_dump/pg_dump.c happen to have hard-coded PUBLIC role name.
It completly breaks dumps when run with Turksh locale setting. In my
opinion making it lower-case would do much good and no harm. A mini
patch is given below.
On the other hand, I was thinking about wrapping all the identifiers
- Original Message -
From: Christopher Kings-Lynne [EMAIL PROTECTED]
To: Nicolai Tufar [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, December 01, 2002 4:05 AM
Subject: Re: [HACKERS] Hard-coded PUBLIC in pg_dump
H...does putting double quotes (eg. PUBLIC) around the public word
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
... but considering that SQL92 clearly lists it as
a reserved word, there's not a lot of ground for that complaint to stand
on.
I'd prefer shifting PUBLIC back to the true-keyword category over any
of the other workarounds
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Ohhh ...
Nicolai, are you running with a client encoding different from server
encoding?
Got it!
Gentlemen, thank you very much for assistance. The body of evidence was
slowly
growing, then, finaly Tom Lan's message have
Comment in {identifier} section in src/backend/parser/scan.l states:
[...]
* Note: here we use a locale-dependent case conversion,
* which seems appropriate under SQL99 rules, whereas
* the keyword comparison was NOT
:
Nicolai Tufar [EMAIL PROTECTED] writes:
So I have changed lower-case conversion code in scan.l to make it purely
ASCII-based.
as in keywords.c. Mini-patch is given below.
Rather than offering a patch, you need to convince us why our reading of
the SQL standard is wrong. (Oracle does
I always wandered if VACUUM is the right name for the porcess. Now, when
PostgreSQL
is actively challenging in Enterprise space, it might be a good idea to give
it a more
enterprise-like name. Try to think how it is looking for an outside person
to see
us, database professionals hold lenghty
68 matches
Mail list logo
