On Saturday, November 27, 2010, Nikhil Sontakke 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 (pgsql-hackers@postgresql.org)
> To ma
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.
>&g
"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
>>
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
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
-
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 look
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
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
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 migh
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 lea
"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. F
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.
-
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 l
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' lan
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
$ LANG=es_MX
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
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
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 Engl
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 t
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 postgresql
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
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 projec
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.
--
"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. Chest
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
ftp://ftp.postgresql.or
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 -I../../../../sr
NunoACHenriques <[EMAIL PROTECTED]> writes:
> I've issued a query like the one below and the server timed out after
> 180min (+/-). The query "construct_warehouse()" can last well above the
> 180min because it fills a table with millions of tuples...
>
> -
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
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, ri
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.
&
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.
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,
M
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 timesta
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 c
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 i
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
> > c
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
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, a
Attached is a pacth against 7.2 which adds locale awareness to the
character classes of the regular expression engine. Please consider
including this feature to postgreSQL.
Regards,
Manuel.
*** src/backend/regex/regcomp.c.org Sun Mar 17 16:39:13 2002
--- src/backend/regex/regcomp.c Sun Mar 17 1
39 matches
Mail list logo
