Priem, Alexander said:
> Would lc-collate=C be bad in combination with UNICODE encoding? What
> lc-collate setting would you recommend for UNICODE encoding which will
> provide good sorting for all (most) common languages? (dutch, english,
> french, german)
It seems that LC_COLLATE=C is not a good
Dann Corbit wrote:
A following VACCUM brings back return times to 'start' -
but I cannot
run VACUUM any other minute (?). And it exactly vaccums as
many tuples
as I updated.. sure thing:
Why not? You only have to vacuum this one table. Vacuuming it
once a minute
Peter Eisentraut said:
> Am Donnerstag, 22. April 2004 13:17 schrieb John Sidney-Woollett:
> You get your strings sorted in binary order of the UTF-8 encoding, which
> is probably not very interesting, but it's possible.
Agreed.
>> Is it also true that if LC_COLLATE != 'C' that indexes cannot be
Hello,
Well it of course depends on what you are doing. Traditionally I would
say, "Are you nuts?" but it really depends
on what you are doing. It is all about risk... if PostgreSQL freaks out
and takes out the machine, what will happen
to the MS SQL server? What about cost associated with downt
John,
> I guess if I have some time I should build some different DBs with
> different combinations of encoding and collations and summarise my
> findings using different types of data and sort/search commands, in case
> anyone else has the same level of confusion that I do...
that'd be excellent.
Tom Lane said:
> "John Sidney-Woollett" <[EMAIL PROTECTED]> writes:
>> Please can someone explain why Postgres cannot recognize that objects
>> (referenced by pl/pgsql functions) whose OID no longer exists could in
>> fact be found (as new objects) if the function was reparsed and compiled
>> again
On Wed, Apr 21, 2004 at 09:12:27PM -0400, Jon Pastore wrote:
> This perl script is designed to handle payment posting for an application we
> developed. It runs fine on our development server which is running apache
> 1.3.27 on ES 2.1
>
> on the production server the script hangs and we see the
On Thu, Apr 22, 2004 at 02:07:39PM +0100, John Sidney-Woollett wrote:
> There are loads of instances (db in flux, move table to another schema
> etc) why you might want/need to drop a table, and recreate it. But in
> Postgres, you have to reapply all DDL statements to the db that referenced
> that
I'm not ruling out the idea of running with a separate linux box, but there
are some strong reasons to stick with the MS box. So, your point is well
taken.
That aside, however, I still need to draw from various people's experience
to get a feel for any problems that may arise when running next to
Alvaro Herrera said:
> Actually, in your example the only thing you need to do is close the
> connection and reconnect. I agree it would be nice to recompile the
> function automatically, but it's not as bad as you put it.
Thanks, I wasn't aware of that.
John Sidney-Woollett
---
On Thu, Apr 22, 2004 at 01:58:14PM +0200, Karsten Hilbert wrote:
> a) it seems SQL ledger wants to store data in PostgreSQL
> b) I assume it wants to store *financial* data
> c) local/all/trust means *all* *local* users are *trusted*, eg
>don't require any authentication, hence system account
On Wed, 2004-04-21 at 15:19, scott.marlowe wrote:
> Are you running the megaraid 2 driver or the older 1.18 series? Just
> wondering.
We started with the megaraid driver distributed with 2.6.3, which is
megaraid v2.00.3. With that driver we weren't able to insert more than 5
million row befor
> I don't think so. I don't see why there should be a difference in
> executing an insert statement direct, or trought a function.
> You would still be simply executing an insert on a table, wich implies
> that the user has to have sufficient rights on that table.
Permissions problems can take
Tom Lane said:
> C locale basically means "sort by the byte sequence values". It'll do
> something self-consistent, but maybe not what you'd like for UTF8
> characters.
OK, that explains that. I guess I will need to try it out to see what the
effect is on extended character sets.
>> Our database
Please can someone explain why Postgres cannot recognize that objects
(referenced by pl/pgsql functions) whose OID no longer exists could in
fact be found (as new objects) if the function was reparsed and compiled
again.
Here's an example:
Create table t1 (f1 integer);
insert into t1 values (1)
> I'd say you should first decide if you really need Unicode. If you're
> dealing exclusively with English/French/Spanish/German or so and if
> you're pretty sure you'll never touch Polish/Russian/Chinese, you can
> stick to Latin-1 or Latin-9 and happily ignore Unicode.
But wouldn't it be better
"Tumurbaatar S." <[EMAIL PROTECTED]> writes:
> The following function returns this error:
> pg_query(): Query failed: ERROR: permission denied for relation customers
> CONTEXT: PL/pgSQL function "newprofile" line 8 at SQL statement
> What is wrong here?
By default functions execute with the perm
Am Donnerstag, 22. April 2004 13:17 schrieb John Sidney-Woollett:
> Does anyone know what the effect of --lc-collate=C --encoding=UNICODE will
> be for sorts (and indexes?) when a multibyte unicode character is
> encountered?
You get your strings sorted in binary order of the UTF-8 encoding, which
"John Sidney-Woollett" <[EMAIL PROTECTED]> writes:
> Does anyone know what the effect of --lc-collate=C --encoding=UNICODE will
> be for sorts (and indexes?) when a multibyte unicode character is
> encountered?
C locale basically means "sort by the byte sequence values". It'll do
something self-c
>
[snip]
>
> I think I looked into this a while ago and couldn't figure out a way to
> discard a message from my MX without downloading it. Any ideas out
> there?
The problem is, again, as I noted earlier, this also breaks the mail
system. Would you really trust blind blocking by IP address no
> > > Do yourself a favour and change authentication type in pg_hba.conf to
> > >
> > > local all trust
> > If you follow this sage advice you'll open up your financial
> > data to anyone happening to have an account on the machine in
> > question. Anyone. Not just people wh
I don't think so. I don't see why there should be a difference in executing an insert
statement direct, or trought a function. You would still be simply executing an insert
on a table, wich implies that the user has to have sufficient rights on that table.
Should anyone think I'm wrong (I'm still
Priem, Alexander said:
> I recreated my entire database (luckily I keep scripts for
> table/index/view
> creation) and initdb-ed it using --lc-collate=C --encoding=UNICODE. In my
> psqlODBC DSN settings I added "set client_encoding='LATIN9';" to the
> Connect Settings and that solved all my problem
>
> Jim Seymour wrote:
> > Karsten Hilbert <[EMAIL PROTECTED]> wrote:
> >>If you follow this sage advice you'll open up your financial
> >>data to anyone happening to have an account on the machine in
> >>question. Anyone. Not just people who also happen to have
> >>*PostgreSQL* DB accounts.
> >
Some additional infos to my problem
Old System: Postgresql 7.3.2
New System: Postgresql 7.4.1
pg_dump (PostgreSQL) 7.3.2
(pg_dumpall -g GLOBALobjects.sql)
pg_dump -s DATABASE > DBschema.sql
pg_dump -Fc DATABASE > DBdata.tar
and rebuilt on the new system with:
psql (PostgreSQL) 7.4.1
1.
Hi everyone,
I solved the problem with the special characters (thanks to you all).
I recreated my entire database (luckily I keep scripts for table/index/view
creation) and initdb-ed it using --lc-collate=C --encoding=UNICODE. In my
psqlODBC DSN settings I added "set client_encoding='LATIN9';" to
My guess is that the user has no (insert) rights on the table Customers.
Try something like this for your table:
GRANT [your options] ON TABLE Customers TO SomeCustomer; (or to everyone if that's
easyer)
where your options best includes SELECT and INSERT
Regards,
Stijn Vanroye
> The following
Hi
I'm trying to restore tsearch2 featuring database like discribed in the
'tsearch-V2-intro' document.
(http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/tsearch-V2-intro.html)
In point '5) Restore the data for the database' I get the following Error:
pg_restore: ERROR: duplicate key
The following function returns this error:
pg_query(): Query failed: ERROR: permission denied for relation customers
CONTEXT: PL/pgSQL function "newprofile" line 8 at SQL statement
What is wrong here?
CREATE SEQUENCE CustomerID;
CREATE TABLE Customers
(
CustomerID INTEGER NOT NULL DEFAULT n
So if I understand correctly, I could best try the following :
* Create a new database, using UNICODE encoding, since this supports the
largest character set (inc. Euro-sign etc.)
* Then, set the client-encoding to LATIN9, so that clients get support for
special dutch characters. The client-encod
> Am Donnerstag, 22. April 2004 09:48 schrieb Stijn Vanroye:
> > Wouldn't it be better if I just set my client encoding to
> UNICODE in stead
> > of LATIN1? I suppose the UNICODE encoding set is understood
> by windows (and
> > delphi), since I write progs for a win enviroment.
Peter Eisentraut
Am Donnerstag, 22. April 2004 09:48 schrieb Stijn Vanroye:
> Wouldn't it be better if I just set my client encoding to UNICODE in stead
> of LATIN1? I suppose the UNICODE encoding set is understood by windows (and
> delphi), since I write progs for a win enviroment.
That really depends exclusively
> > What I personally don't understand is: if all my databases
> > are UNICODE, why do I have to set the Client encoding to latin1
> > to get a correct result?
Karsten Hilbert wrote:
> Because LATIN1 isn't just a subset of UNICODE. If the data
> coming out of the database *is* UNICODE *and* your c
Quoth [EMAIL PROTECTED] ("Uwe C. Schroeder"):
> I concur. However the problem SAP had some 18years ago when they
> invented their system were massive differences between
> databases. The scope they had in mind didn't allow for whole
> database layers to be redundant just for the sake of being able
34 matches
Mail list logo
