Re: [GENERAL] Dump functions alone

> Any help in getting function argument names is appreciated. Thank you take a look at pg_catalog.pg_get_function_arguments(oid) regards, jan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-gen

Re: [GENERAL] update from 9.0rc1 to 9.0

>> is an initdb and pg_upgrade required when upgrading from 9.0rc1 to final 9.0? >> there is no mention about that in the release notes. > > the assumption is 'no' on rc->rc or rc-releases generally unless > specifically indicated in the release notes that you must do so. it > never hurts to keep

Re: [GENERAL] update from 9.0rc1 to 9.0

>> is an initdb and pg_upgrade required when upgrading from 9.0rc1 to final 9.0? >> there is no mention about that in the release notes. > > No, there were no system catalog changes between 9.0rc1 and 9.0. thank you bruce. regards, jan -- Sent via pgsql-general mailing list (pgsql-general@post

Re: [GENERAL] update from 9.0rc1 to 9.0

>> is an initdb and pg_upgrade required when upgrading from 9.0rc1 to final 9.0? >> there is no mention about that in the release notes. > > No, there were no system catalog changes between 9.0rc1 and 9.0. thank you bruce. regards, jan -- Sent via pgsql-general mailing list (pgsql-general@pos

[GENERAL] update from 9.0rc1 to 9.0

hi, is an initdb and pg_upgrade required when upgrading from 9.0rc1 to final 9.0? there is no mention about that in the release notes. regards, jan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsq

Re: [GENERAL] INSERT RETURNING and partitioning

hi, On Jul 21, 2010, at 10:02, "pdov...@tiscali.it" wrote: Hi, I'm testing the system with these two insert commands: 1) this command returns an empty result set: insert into support.master (a) VALUES (2) RETURNING seq; 2) this command returns correctly the seq (serial) value into result

Re: [GENERAL] Getting iPhone Simulator App to compile with libpq on Snow Leopard

standard c (libSystem) function. make shure you have linked your library (libpq) against the same versions of standard libraries as you try with your iphone-app. check your linker options, specially -isysroot. you can check later to which libSystem your lib or app was built with: otool -L regards

Re: [GENERAL] More Snow Leopard problems...

hi jerry, try killing mDNSResponder before restarting postgres: sudo killall mDNSResponder hopefully apple fixes this dns-problems in 10.6.1. regards, jan otto The rascal gets respawned immediately ;( Of course it will be respawned, but all the cache is disposed (the broken entries

Re: [GENERAL] More Snow Leopard problems...

didn't configure it) would make a difference. try killing mDNSResponder before restarting postgres: sudo killall mDNSResponder hopefully apple fixes this dns-problems in 10.6.1. regards, jan otto -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes t

Re: [GENERAL] Snow Leopard and plpython problem

Configure completes ok. When I do a "make 2>mylog.log" i have tried configuring an building with the same options as you and it compiles without an error or warning about python. regards, jan otto -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make ch

Re: [GENERAL] Snow Leopard and PG 8.4 problems....

blems with dblink on Snow Leopard? i dont use dblink so i cant say if it is broken on my machine too. regards, jan otto -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Space for pg_dump

On Apr 20, 2009, at 7:35 PM, Alvaro Herrera wrote: Jan Otto wrote: If you have big toast tables you get wrong results with the query suggested at http://wiki.postgresql.org/wiki/Disk_Usage because it takes the toasted values not into account. Now a fixed query which gets the sizes of the

Re: [GENERAL] Space for pg_dump

Hi, Rainer Bauer writes: Greg Smith wrote: Since running an entire pgdump can take forever on a big database, what I usually do here is start by running the disk usage query at http://wiki.postgresql.org/wiki/Disk_Usage Interesting. However, the query gives an error if the table name co

Re: [GENERAL] Counting unique rows as an aggregate.

I must be missing something, because I don't see why you couldn't do SELECT count(distinct make), count(distinct color) from table WHERE >criteria<; I didn't explain well, I want the count of each distinct value in a column, eg, if the color column has 50 rows, 20x'red', 10x'green', 20x'blue'

Re: [GENERAL] Update taking forever

Hi Oliver, currently idle except for the update statement. Any suggestions why it takes so long to update a couple million rows? update characters set last_update = null Try to update only rows that not already null. update characters set last_update = null where last_update is not null;