Dear Hackers,
We are having really hard times with the PostgreSQL spanish list
hosted here in México, mainly because the lack of
administration. That's really sad since we are a well established and
growing community. So, we would like to know if it's possible that the
list is hosted by
Hi, I have found what I thing is a quite annoying behaviour of
Postgres (psql). When you type (and ask for complation) for some
string that has some characters not in the ASCII encoding it requires
a double quote on it, however if you don't put those double quotes
around it, you can still execute
Tom Lane [EMAIL PROTECTED] writes:
... in other words, it doesn't require the double quotes. I don't see
the value of being more restrictive. Why is this annoying?
Note also that using iso-8859-1 is not more restrictive, but just the
opposite. Using iso-8859-1 will be useful also for English
Tom Lane [EMAIL PROTECTED] writes:
Manuel Sugawara [EMAIL PROTECTED] writes:
Hi, I have found what I thing is a quite annoying behaviour of
Postgres (psql). When you type (and ask for complation) for some
string that has some characters not in the ASCII encoding it requires
a double
Tatsuo Ishii [EMAIL PROTECTED] writes:
I think we need to fix that as well.
I do agreee, however, we have to start somewhere.
Regards,
Manuel.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
According to POSIX -regex (7)-, standard character class are:
alnum digit punct
alpha graph space
blank lower upper
cntrl print xdigi
Many of that classes are different in different locales,
Tatsuo Ishii [EMAIL PROTECTED] writes:
I don't think character classes are applicable for most mutibyte
encodings. Maybe only the exeception is Unicode?
Maybe, and is the only one I need ;-)
Peter Eisentraut [EMAIL PROTECTED] writes:
Basically, you manually preprocess the patch to
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
En Tue, 16 Apr 2002 19:21:50 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] escribi?:
Here is a patch based on this discussion.
I still think the xdigit class could be handled the same way the digit
class is (by
Bruce Momjian [EMAIL PROTECTED] writes:
Tatsuo Ishii wrote:
I miss that case :-(. Here is the pached patch.
Regards,
Manuel.
I also suggest that cclass_init() is called only if the locale is not
C.
OK, patch on hold while this is addressed.
Here is a patch which
Alvaro Herrera [EMAIL PROTECTED] writes:
En 17 Apr 2002 22:53:32 -0600
Manuel Sugawara [EMAIL PROTECTED] escribió:
Bruce Momjian [EMAIL PROTECTED] writes:
Tatsuo Ishii wrote:
I miss that case :-(. Here is the pached patch.
Regards,
Manuel.
I also suggest
Hi,
Something is pretty broken in redhat 7.3 but I'm not sure what and I
don't have time to dig further
masm@test=# select cast('1967-04-18' as timestamptz);
timestamptz
1967-04-17 18:00:00-06
(1 row)
masm@test=# select cast(cast('1967-04-18' as date) as
Lamar Owen [EMAIL PROTECTED] writes:
Filed on Red Hat's Bugzilla system as bug# 65227, as I can reliably
reporoduce this bug here, and PostgreSQL 7.2.1 on Red Hat 6.2 on
SPARC does not exhibit the bug.
Thanks for filling that report. I couldn't remember what had forgotten
;-)
Regards,
Lamar Owen [EMAIL PROTECTED] writes:
Where would we go to ferret out the source of this bug? More to the
point: we need a test case in C that could expose this as a glibc
bug.
Seems like mktime(3) is having problems with dates before the
epoch. Attached is the a program to test this. The
Lamar Owen [EMAIL PROTECTED] writes:
On Monday 20 May 2002 08:08 pm, Manuel Sugawara wrote:
Where would we go to ferret out the source of this bug? More to the
point: we need a test case in C that could expose this as a glibc
bug.
Seems like mktime(3) is having problems with dates
Trond Eivind Glomsrød [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug,
not a glibc bug.
The question is: how this thing didn't show up before? ISTM that
someone is not doing his work correctly.
PostgreSQL needs fixing.
Arguably, however, right
This thread is getting pretty annoying rather than constructive. By
the mean time I can see the users of many db's running under linux
loudly complaining.
As a user of both products (glibc and postgres), I would like to see a
good compromise in both sides. For instance: postgreSQL will implement
Guys,
postgresql7.3b1 does not build :-(, seems like a missing multibyte
directory
'
| make[4]: Entering directory
|`/home/masm/download/postgresql-7.3b1/src/backend/utils/time'
| gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
Tom Lane [EMAIL PROTECTED] writes:
So it would seem. The utils/mb directory is certainly there in the full
tarball that I pulled from ftp.us.postgresql.org this morning. How did
you acquire your source tree, exactly?
The file is postgresql-base-7.3b1.tar.gz from
Marc G. Fournier [EMAIL PROTECTED] writes:
You need either the 7.3b1.tar.gz (which is everything), or you need to get
all the various -*- parts (which are more manageable)
Oh, well. Thanks
Regards,
Manuel.
--
No es que no puedan hallar la solución: es que no ven el problema.
G.K. Chesterson
Bruce Momjian [EMAIL PROTECTED] writes:
You need either the 7.3b1.tar.gz (which is everything), or you need to get
all the various -*- parts (which are more manageable)
I am confused. Are you saying the base file isn't compilable?
My idea was that it is.
Regards,
Manuel.
Hi,
Starting postgres as part as of the normal boot process of my db
server (up2date FC3) leads to an ``unusable'' database since it does
not set the locale properly. For instnace:
test=# select 'í' ~ '[[:lower:]]';
?column?
--
f
(1 fila)
However, starting postgres as
$
Here is a test case for a previously reported bug (see
http://archives.postgresql.org/pgsql-general/2005-11/msg01235.php):
initdb using es_MX.ISO-8859-1, start postgres using es_MX.UTF-8 and
execute:
create procedural language plperl;
create or replace function foo() returns int as 'return 1'
Tom Lane [EMAIL PROTECTED] writes:
(Your proposed fix seems entirely useless ...
While there are reasons to argue that's Perl fault, IMO, an
environment that reflects the current state of the host program is a
good compromise, and behave environment-consistent is also a good
compromise for
Now that Oracle supports i18n dependant behavior in its to_char
formatting functions (at least for its 10g release) I was wondering if
a patch to support this in PostgreSQL will get accepted. I was hoping
to work on this now that I have some spare time.
Regards,
Manuel.
Qingqing Zhou [EMAIL PROTECTED] writes:
Can you give a small introduction of i18n and what's your plan in
PostgreSQL?
i18n == Internationalization (maybe I should say l10n ==
localization). This means that to_char functions might lead to
different results depending on the i18n settings. For
Tom Lane [EMAIL PROTECTED] writes:
I thought to_char already had i18n behavior. What exactly are you
thinking of changing?
The modifiers that are suitable to localize. Month and day names comes
to mind and maybe others, I'm not sure what the state of the code is,
but I can say that, at least,
Tom Lane [EMAIL PROTECTED] writes:
Can we spell the names differently but keep to the same field widths?
I can see where it might cause problems to change the widths --- other
than that, no objection.
Quite impossible. But if someone is relaying in the current behavior
of to_char she might
Gavin Sherry [EMAIL PROTECTED] writes:
There's some functionality in 10g which PostgreSQL does not have:
Good to know. I'm not an Oracle expert, actually I knew this reading
an article in a past issue of the Oracle's magazine about i18n;
essentially they were talking about how easy was for an
Larry Rosenman [EMAIL PROTECTED] writes:
what version of bison are you using? I believe we require 1.875
these days.
It would be nice to be able to say --without-ecpg at configure time.
Ecpg is the only part of pg that requires this version of bison and
and is not a core part of the project,
I did the es translation of pg_dump and while looking at the code I
found that in several places the char * representation of Oid's is
used instead of the oid itself. Any one knows why is done this
way?
Regards,
Manuel.
---(end of broadcast)---
TIP
Hi all,
I'm running PostgreSQL v 8.1.4 and found a query that returns tuples
that does not satisfy the WHERE clause, the query is:
select * into errores_20071 from (
select r.id, r.trayectoria_id, r.grupo_id,
regacd.insc_registra_grupo(trayectoria_id, grupo_id, true, false, true) as
error
Tom Lane [EMAIL PROTECTED] writes:
You seem to have worse problems than that, because as given the
insc_registra_grupo function never returns non-NULL
Actually the function (and the database) is quite complex and was
trimed just to test the problem.
I suspect pilot error --- perhaps looking
Hi,
I have a simple query that uses digest(data, 'sha1') and consistently
crashes the backend (tested in two different machines):
ciencias=# select version();
version
Manuel Sugawara [EMAIL PROTECTED] writes:
Hi,
I have a simple query that uses digest(data, 'sha1') and consistently
crashes the backend
The problem is with null arguments:
ciencias=# select digest(null, 'sha1');
el servidor ha cerrado la conexión inesperadamente,
probablemente
Marko Kreen [EMAIL PROTECTED] writes:
On 8/24/07, Manuel Sugawara [EMAIL PROTECTED] wrote:
Manuel Sugawara [EMAIL PROTECTED] writes:
I have a simple query that uses digest(data, 'sha1') and consistently
crashes the backend
The problem is with null arguments:
ciencias=# select digest
Tom Lane [EMAIL PROTECTED] writes:
Manuel Sugawara [EMAIL PROTECTED] writes:
Marko Kreen [EMAIL PROTECTED] writes:
In 8.0 the pgcrypto functions were non-strict and checked for NULLs.
In 8.1 they were made STRICT.
In 8.2 the NULL check were removed from code.
Not an smart move IMHO, I
On Saturday, November 27, 2010, Nikhil Sontakke nikkh...@gmail.com wrote:
Hi, a very good business company, I suggest you go to see:
mobiles3gs.com, and now all of products enjoy great discount, saving
time and money.
h--)
--
Sent via pgsql-hackers mailing list
37 matches
Mail list logo
