Re: [GENERAL] Problem V8.1.4 - providing pwd for commandline tools doesn't

I don't understand why the change should be "more secure", but I see that nobody took care about the possible consequences for installation scripts, third party applications and so on. :-((( If you change such essential behaviour (the old behaviour of the commandline tools did work well since 8.0!

Re: [GENERAL] Problem in Pg 8.1.4 with CREATEDB

Yes, we have the same problem! Refer to the thread with the subject "Problem V8.1.4 - providing pwd for commandline tools doesn't work anymore". They seem to have change the old behaviour of the commandline tools, which worked well since 8.0! I don't understand why the change should be "more secu

[GENERAL] Problem V8.1.4 - providing pwd for commandline tools doesn't work anymore

The latest version (V8.1.4) breaks the setup process of our application's installation wizard. We used to call "createdb.exe" and piped the password for the postgres user (which has been entered by the user in our setup wizard's dialogs) into it. With version V8.1.4 this is not possible anymore, t

Re: [GENERAL] Query to check existence of stored procedure?

Hi Jim, >> select count(*) from pg_proc where proname = 'your_function'; >> > don't forget about schema's, you will need to join with > pg_namespace.oid and pg_proc.pronamespace your answer looks a little bit cryptic for me being somebody who hasn't had to dive into the pg_... tables yet. :-) W

[GENERAL] Query to check existence of stored procedure?

Hi Newsgroup, I need a query which can check for the existence of a certain stored procedure. (The pendant for MS SQL is IF EXISTS (SELECT * FROM "sysobjects" WHERE "id" = object_id(N'"MyTestStoredProcedure"') and OBJECTPROPERTY("id", N'IsProcedure') = 1) ... ) Any help would be appreciated! :-

[GENERAL] Indices for select count(*)?

Hi, thank you for your answer. Regarding the performance flow when trying to find out how many records are currently being stored in the table, I don't see how an index should help... Nevertheless we've created an unique index on "ID" but SELECT count("ID") from "XYZ" still takes 35 seconds*.

[GENERAL] Newbie Question: FAQ for database optimization?

Hi, is there a newbie's FAQ / book / link for "howto optimize databases with PostgreSQL"? Background: Customer has the Windows* (sorry ) Postgres 8.1.0 standard installation "out of the box". A table has 2.5 mio records. No indizes defined, primary key (sequence) does exist. In pgAdmin "sele

Re: [GENERAL] [pgsql-de-allgemein] Query SELECT * sehr langsam

Hi Axel, I have exactly the same problem!!! Seems to be a conceptional problem of libpq (or my usage of it) in my case. Probably in yours, too... Refer to the other thread with subject "Problem: libpq, network traffic, memory usage". HTH, Alexander. ---(end of broa

Re: [GENERAL] Problem: libpq, network traffic, memory usage

Hi Andreas, The same question was yesterday on [pgsql-de-allgemein] ;-) Yes - I just found it. :-) But I don't know whether it is really the same prob. You have selected _ALL_ records, you got all records. Thats the point. I SELECTed them, that's right, but I didn't FETCHed them. I thought t

Re: [GENERAL] Problem: libpq, network traffic, memory usage

Hi Scott, try declare cursor xyz as select ... fetch 100; and see how that works. sorry for probably asking such a stupid question, but we are using a PQexec(). Where should I specify that cursor declaration? BTW: When executing BEGIN WORK; DECLARE "test" CURSOR FOR SELECT * FROM "TEST"

[GENERAL] Problem: libpq, network traffic, memory usage

Dear NG, I have a serious performance flaw, when using postgresql 8.1 (other versions haven't been tested) with libpq. When executing a select * from "xyz" 1) and "xyz" contains 300'000 records, it takes more than 60 seconds for the query just to complete. First I thought it is a perfor