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 discus
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 locale-depen
.l if the locale is "tr_TR"?
Because for many folks setting locale to Turkish would
render their database unusable. For, god forbid, if your
sql has a column name written in capitlas including "I".
It is not working. So I deeply believe that PostgreSQL community
have to provid
- 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}
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
- 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 workarou
- 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 e
>> 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 comman
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
Na
27;;
}else{
*np++ = *p;
}
Regards,
Nicolai
-------
Nicolai Tufar wrote:
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert lo
e shall
I implement?
Regards,
Nicolai Tufar
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
x86, 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
-
ion 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.
think that importing some else's solution
is the way to go. Tom, 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)
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 r
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
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
> > usable replacem
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
> wr
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
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.
Under win32 I am sti
On 6/17/05, Josh Berkus 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 around to this
set to -1 when not yet initialized, 0 if
locale is not Turkish and 1 if locale
is Turkish.
It might not be the way it is usually
done in PostgreSQL
source code. Could you pleas
advise if the name I chose
is appropriate and whether there is a more appropriate
place to put declaration and initial
> I still don't much like having a locale-specific wart in the parser
> (and the code you give could not work anyway --- for starters, the
> first argument of setlocale is not a pointer).
Aw, I see, my code broken. I got confused by locale_.._asign()
family
if functions. Sure, first argument
"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
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
by what. Especially that all those sort
methods and functions are not hard-coded 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.
tings 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&
tings and
it is wrong! I will contact glibc team now.
Thanks a lot for help.
Regards,
Nicolai Tufar
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
> 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 co
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]
> Subje
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 B
s why 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-
> F
> -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 l
> -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
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
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
>
> I've committed the attached fix, which I believe will solve this
> problem. Could you test it?
Thank you very much for your effort and attention!
I am not sure I am testing the right version. I am testing the
one with R
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Hmm. It seems that tr_TR has problems much more extensive than you've
> indicated previously. I was able to get through initdb with the
attached
> additional patch, but the regression tests fail in several places.
> It look
> -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
s 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
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 n
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 b
ww.pgbuildfarm.org/cgi-bin/show_log.pl?nm=fantail&dt=2004-12-06%2023:04:43
Best regards,
Nicolai Tufar
---(end of broadcast)---
TIP 8: explain analyze is your friend
for
such a purpose. Also the used to be P390 - personal 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 ch
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
r your efforts.
I will open a bottle 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?
> >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
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 b
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?
http://www.postgresql.org/do
printf()
from now on.
I would like volunteer 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]
echnology
3. If IBM refuses, 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.
---
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 (cust
BM applied 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
so be hosted there.
>
> We could then sync the translations either regularly (e.g., once a week)
> or only at release time. Of course we would need to mirror all the
> branches there.
>
> Comments?
Perfectly fine. Please go ahead.
> --
> Peter Eisentraut
Nicolai Tufar
T
egression test
produced wither 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
similar solution, for every parameter
extract formatting placeholder 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 regar
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
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)--
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
/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
On Sun, 13 Feb 2005 19:06:34 -0500 (EST), Bruce Momjian
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
> port/snprintf.c.
> One
> 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:
>
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
Nic
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 Hagand
nd. Bruce, could you
take 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
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. Regressi
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 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
wrote:
> Nicolai Tufar wrote:
> > On Tue, 1 Mar 2
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$
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 HAVE_LONG_LONG_INT
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
> http://www.freebsd.org/cgi/man.cgi?query=snprintf&apropos=0&sektion=3&manpa
72 matches
Mail list logo
