=?ISO-8859-2?Q?S=FCn?= <[EMAIL PROTECTED]> writes:
> If you use Latin2 encoding, you can not have 'bssz' and 'bszsz' in an
> unique column in the same time.
AFAICS this means that your locale definition considers these strings
equal.
It is possible that the real problem comes from using an encod
Hello,
If you use Latin2 encoding, you can not have 'bssz' and 'bszsz' in an
unique column in the same time.
Is this a known bug? Do you have any solution? (I use Latin2 encoding,
because I want to order by names, which contains accent characters.)
[EMAIL PROTECTED]:~> psql template1
Welcome t
Adam Kempa <[EMAIL PROTECTED]> writes:
> I've been installed Postgres 7.4.2 on FreeBSD system and when load
> average grow up i've error in postgres like this:
>ERROR: permission denied for function varchar
>ERROR: permission denied for function varchar
> and then postgres crashes.
>
On Fri, 14 May 2004 08:21:28 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Yes. It was supposed to move to http://www.pygresql.org, but that
> > web site doesn't seem to exist anymore.
>
> Hmm. whois shows the pygresql.org domain as PENDING DELETE,
Dear support,
In the unfortuenate case that the pygreSQL directory won't be re-added in future
PostgreSQL versions, then, at the least, configuring PostgreSQL with the --with-python
option should give some kind of error/warning when the directory is empty (and also an
instruction of what to do)
Hello
I've been installed Postgres 7.4.2 on FreeBSD system and when load
average grow up i've error in postgres like this:
ERROR: permission denied for function varchar
ERROR: permission denied for function varchar
and then postgres crashes.
LOG: server process (PID 9787) was terminated
Dear Bruce,
> > > Well, if I issue a "REVOKE" and the rights are not revoked and could never
> > > have been because I have no right to issue such statement on the object, I
> > > tend to call this deep absence of success a "failure".
> >
> > > If I do the very opposite GRANT, I have a clear "per
"=?iso-8859-2?Q?Gyenese_P=E1l_Attila?=" <[EMAIL PROTECTED]> writes:
> REASON IS:
> SELECT 365*1000 ;
> result: -644967296
> wrong
This isn't a division problem --- the difficulty is there's no check for
overflow in int4 multiplication. (Nor in any of the other integer
arithmetic operations,
pgsql-7.4.2
I think it's not a bug, just interesting results:
SELECT 9223372036854775807/(365*1000) ;
result: -14300526699
wrong
SELECT ( 9223372036854775807/365 )/1000 ;
result: 2526951242
good
SELECT ( 9223372036854775807::real /(365*1000) ) ;
result: -14300526699,6589
w
