Re: [HACKERS] Should I implement DROP INDEX CONCURRENTLY?

2011-12-31 Thread Simon Riggs
On Fri, Dec 30, 2011 at 10:20 PM, Peter Eisentraut wrote: > On ons, 2011-08-24 at 11:24 -0700, Daniel Farina wrote: >> I was poking around at tablecmds and index.c and wonder if a similar >> two-pass approach as used by CREATE INDEX CONCURRENTLY can be used to >> create a DROP INDEX CONCURRENTLY,

[HACKERS] alternate psql file locations

2011-12-31 Thread Andrew Dunstan
It's not a big thing, but I just found myself in a shared environment wanting to be able to set alternative locations for the psql startup file and history. I know there's the HISTFILE variable, but I can't easily set that automatically unless I can at least have my own .psqlrc. ISTM it should

Re: [HACKERS] alternate psql file locations

2011-12-31 Thread Alvaro Herrera
Excerpts from Andrew Dunstan's message of sáb dic 31 12:52:02 -0300 2011: > It's not a big thing, but I just found myself in a shared environment > wanting to be able to set alternative locations for the psql startup > file and history. I know there's the HISTFILE variable, but I can't > easily

Re: [HACKERS] alternate psql file locations

2011-12-31 Thread Aidan Van Dyk
On Sat, Dec 31, 2011 at 3:17 PM, Alvaro Herrera wrote: > > Excerpts from Andrew Dunstan's message of sáb dic 31 12:52:02 -0300 2011: >> It's not a big thing, but I just found myself in a shared environment >> wanting to be able to set alternative locations for the psql startup >> file and history.

[HACKERS] Add protransform for numeric, varbit, and temporal types

2011-12-31 Thread Noah Misch
Building on commit 8f9fe6edce358f7904e0db119416b4d1080a83aa, this adds protransform functions to the length coercions for numeric, varbit, timestamp, timestamptz, time, timetz and interval. This mostly serves to make more ALTER TABLE ALTER TYPE operations avoid a rewrite, including numeric(10,2) -

Re: [HACKERS] pg_upgrade and relkind filtering

2011-12-31 Thread Noah Misch
On Mon, Dec 05, 2011 at 05:06:37PM -0500, Bruce Momjian wrote: > Pg_upgrade has the following check to make sure the cluster is safe for > upgrading: > > res = executeQueryOrDie(conn, > "SELECT n.nspname, c.relname, a.attname > " >