Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Robert Haas
On Dec 23, 2009, at 1:15 PM, Tom Lane wrote: Robert Haas writes: On Dec 23, 2009, at 3:52 PM, Tom Lane wrote: Uh ... I don't see what that fixes? If CONCURRENTLY can be a column name this is still ambiguous. How? Because CONCURRENTLY can still be reduced as tricky_index_name, so it st

Re: [HACKERS] join ordering via Simulated Annealing

2009-12-23 Thread Adriano Lange
Em 22-12-2009 22:23, Jan Urbański escreveu: > o) the initial state is not really a random plan, it's usualy a > left-deep tree (and is very inefficient) and this might skew results. Maybe a QuickPick + SA. http://www.springerlink.com/content/garn64gt61ju5xfa/ http://portal.acm.org/citation.cfm?do

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Bruce Momjian
Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > I wasn't aware enum ordering is something we tried to maintain. > > One issue is that we are not supporting the addition of enum values even > > for people who don't care about the ordering of enums (which I bet might > > be the majority.) > >

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Andrew Dunstan
Bruce Momjian wrote: I wasn't aware enum ordering is something we tried to maintain. One issue is that we are not supporting the addition of enum values even for people who don't care about the ordering of enums (which I bet might be the majority.) The ordering of enums is defined and to b

Re: [HACKERS] About the CREATE TABLE LIKE indexes vs constraints issue

2009-12-23 Thread Greg Williamson
Jeff Davis wrote: ... > Honestly, I've never used LIKE in a table definition aside from one-off > design experiments. For that kind of thing, what I want is to just get > everything (except perhaps FKs if the above situation applies), and I > adjust it from there. Are there people out there who u

Re: [HACKERS] About the CREATE TABLE LIKE indexes vs constraints issue

2009-12-23 Thread Tom Lane
Jeff Davis writes: > Honestly, I've never used LIKE in a table definition aside from one-off > design experiments. For that kind of thing, what I want is to just get > everything (except perhaps FKs if the above situation applies), and I > adjust it from there. Are there people out there who use L

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Bruce Momjian
Tom Lane wrote: > Greg Stark writes: > > On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane wrote: > >> The reason that isn't implemented is that it's *hard* --- in fact, > >> it appears to be entirely impossible in the general case, unless you're > >> willing to change existing values of the enum on-disk

Re: [HACKERS] About the CREATE TABLE LIKE indexes vs constraints issue

2009-12-23 Thread Jeff Davis
On Wed, 2009-12-23 at 14:55 -0500, Tom Lane wrote: > I think the most natural reading of the syntax > would be "INCLUDING INDEXES means to include everything you made > with CREATE INDEX syntax, while INCLUDING CONSTRAINTS means to > include everything you made with CONSTRAINT syntax". Agreed. >

Re: [HACKERS] what about _PG_fini

2009-12-23 Thread Cédric Villemain
2009/12/23 Tom Lane : > =?ISO-8859-1?Q?C=E9dric_Villemain?= > writes: >> I wonder what is the future of "_PG_fini", documentation say at [1]: >> "Note that _PG_fini will only be called during an unload of the file, >> not during process termination. (Presently, unloads are disabled and >> will ne

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Tom Lane
Greg Stark writes: > On Wed, Dec 23, 2009 at 8:09 PM, Tom Lane wrote: >> If we're going to implement something whose ambitions only extend to >> satisfying pg_migrator's needs, then it should be a specialized >> pg_migrator function. > Fwiw my feeling was the opposite here. It's better to offer

Re: [HACKERS] what about _PG_fini

2009-12-23 Thread Tom Lane
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes: > I wonder what is the future of "_PG_fini", documentation say at [1]: > "Note that _PG_fini will only be called during an unload of the file, > not during process termination. (Presently, unloads are disabled and > will never occur, but this may change

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Greg Stark
On Wed, Dec 23, 2009 at 8:09 PM, Tom Lane wrote: > If we're going to implement something whose ambitions only extend to > satisfying pg_migrator's needs, then it should be a specialized > pg_migrator function. Fwiw my feeling was the opposite here. It's better to offer even limited SQL-level supp

[HACKERS] what about _PG_fini

2009-12-23 Thread Cédric Villemain
Hello dear hackers, I wonder what is the future of "_PG_fini", documentation say at [1]: "Note that _PG_fini will only be called during an unload of the file, not during process termination. (Presently, unloads are disabled and will never occur, but this may change in the future.)" Since 8.2 it i

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Tom Lane
Robert Haas writes: > On Dec 23, 2009, at 3:52 PM, Tom Lane wrote: >> Uh ... I don't see what that fixes? If CONCURRENTLY can be a column >> name this is still ambiguous. > How? Because CONCURRENTLY can still be reduced as tricky_index_name, so it still doesn't know how to parse CREATE INDEX C

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Robert Haas
On Dec 23, 2009, at 3:52 PM, Tom Lane wrote: Robert Haas writes: I'm about to get on a plane, but just to make you hurl here's another half-assed approach. Uh ... I don't see what that fixes? If CONCURRENTLY can be a column name this is still ambiguous. How? ...Robert -- Sent via pgsql

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Tom Lane
Robert Haas writes: > I'm about to get on a plane, but just to make you hurl here's another > half-assed approach. Uh ... I don't see what that fixes? If CONCURRENTLY can be a column name this is still ambiguous. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Robert Haas
On Wed, Dec 23, 2009 at 1:42 PM, Tom Lane wrote: > Greg Stark writes: >> On Wed, Dec 23, 2009 at 6:13 PM, Tom Lane wrote: >>> If there were more than a single member of the class, I might think >>> it was worth the trouble ... > >> A quick glace at the list shows relatively few that actually nee

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Tom Lane
Greg Stark writes: > On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane wrote: >> The reason that isn't implemented is that it's *hard* --- in fact, >> it appears to be entirely impossible in the general case, unless you're >> willing to change existing values of the enum on-disk. > Shouldn't adding new

[HACKERS] About the CREATE TABLE LIKE indexes vs constraints issue

2009-12-23 Thread Tom Lane
In connection with the operator-exclusion patch, Brendan Jurd wrote: > * What to do about INCLUDING INDEXES EXCLUDING CONSTRAINTS -- > Postgres gets this wrong for unique indexes currently. Should we > persist with the existing behaviour or fix it as part of this patch? > My personal feeling was

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Greg Stark
On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane wrote: > Bruce Momjian writes: >> The remaining issue is pg_enum oids.  Because it will be difficult to >> pass an arbitrary number of oids into the backend, the idea was to >> assign each enum value separately.  If we implement this TODO item: > >>      

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Guillaume Smet
On Wed, Dec 23, 2009 at 7:42 PM, Tom Lane wrote: > I'm still not really eager to introduce yet another category of > keywords, but perhaps it is worth doing.  Comments? If we consider that they can now be a problem in pl/pgsql, it might be a good idea to consider it for this release. (I'm thinki

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Tom Lane
Bruce Momjian writes: > The remaining issue is pg_enum oids. Because it will be difficult to > pass an arbitrary number of oids into the backend, the idea was to > assign each enum value separately. If we implement this TODO item: > Allow adding/renaming/removing enumerated values to an e

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Tom Lane
decibel writes: > Is there some reason why OIDs were used for ENUM instead of a general > sequence? Were we worried about people screwing with the sequence? No, we were worried about being able to do enum_out without outside information as to which enum type it is. If you don't mind doubling th

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread Bruce Momjian
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian writes: > > > ... The idea I had was to create a global structure: > > > > > struct pg_migrator_oids { > > > Oid pg_type; > > > Oid pg_type_array; > > > ... > > > } > > > > > This would initialize

Re: [HACKERS] Range types

2009-12-23 Thread decibel
On Dec 15, 2009, at 6:29 PM, Jeff Davis wrote: > On Tue, 2009-12-15 at 18:06 -0600, decibel wrote: >> Now that varlena's don't have an enormous fixed overhead, perhaps it's >> worth looking at using them. Obviously some operations would be >> slower, but for your stated examples of auditing and his

Re: [HACKERS] Re: About "Allow VIEW/RULE recompilation when the underlying tables change"

2009-12-23 Thread decibel
On Dec 19, 2009, at 4:38 PM, Robert Haas wrote: > On Sat, Dec 19, 2009 at 1:56 PM, Caleb Welton wrote: >> I maintain that the approaches that inform the user that they have met that >> condition via ALTER statement failures (Postgres/DB2/Microsoft Bound Views) >> have certain advantages over data

Re: [HACKERS] Removing pg_migrator limitations

2009-12-23 Thread decibel
On Dec 19, 2009, at 9:52 PM, Robert Haas wrote: > On Sat, Dec 19, 2009 at 10:46 PM, Bruce Momjian wrote: >> Tom Lane wrote: Bruce Momjian wrote: > Seems I need some help here. >>> >>> I'm willing to work on this --- it doesn't look particularly fun but >>> we really need it. >> >> You d

Re: [HACKERS] Streaming Rep - 2-phase backups and reducing time to full replication

2009-12-23 Thread decibel
On Dec 22, 2009, at 12:54 PM, Simon Riggs wrote: > 9. Create a recovery command file in the standby server with parameters > required for streaming replication. > > 7. (a) Make a base backup of minimal essential files from primary > server, load this data onto the standby. > > 10. Start postgres

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Tom Lane
Greg Stark writes: > On Wed, Dec 23, 2009 at 6:13 PM, Tom Lane wrote: >> If there were more than a single member of the class, I might think >> it was worth the trouble ... > A quick glace at the list shows relatively few that actually need to > be barred from columns. I could easily see people

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Greg Stark
On Wed, Dec 23, 2009 at 6:13 PM, Tom Lane wrote: > ?> Well still in the realm of overthinking Is there anything to be >> gained by having a class of reserved word which can be used for >> columns but not relations? > > If there were more than a single member of the class, I might think > it wa

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Tom Lane
Greg Stark writes: ?> Well still in the realm of overthinking Is there anything to be > gained by having a class of reserved word which can be used for > columns but not relations? If there were more than a single member of the class, I might think it was worth the trouble ...

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Greg Stark
On Wed, Dec 23, 2009 at 2:58 PM, Tom Lane wrote: > No, not really.  Past the grammar there is no way to tell concurrently > from "concurrently", ie, if we did it like that then you couldn't even > use double quotes to get around it.  Don't overthink this: either we > reserve the word or we don't p

Re: [HACKERS] [COMMITTERS] pgsql: Remove code that attempted to rename index columns to keep them

2009-12-23 Thread Tom Lane
Bruce Momjian writes: > Does this mean this TODO items should be modified to remove the index > name mention? > Add ALTER TABLE RENAME CONSTRAINT, update index name also No, that has nothing to do with this. We already have ALTER INDEX renaming the associated constraint, so I'm not sure

[HACKERS] Re: [COMMITTERS] pgsql: Remove code that attempted to rename index columns to keep them

2009-12-23 Thread Bruce Momjian
Tom Lane wrote: > Log Message: > --- > Remove code that attempted to rename index columns to keep them in sync with > their underlying table columns. That code was not bright enough to cope with > collision situations (ie, new name conflicts with some other column of the > index). Since t

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Tom Lane
I wrote: > Greg Stark writes: >> On Wed, Dec 23, 2009 at 3:54 AM, Tom Lane wrote: >>> Well, this will also break tables and columns named "concurrently". >>> I think the odds of it being a problem are small, but still it is >>> a reserved word that shouldn't be reserved according to the SQL spec.

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Tom Lane
Greg Stark writes: > On Wed, Dec 23, 2009 at 3:54 AM, Tom Lane wrote: >> Well, this will also break tables and columns named "concurrently". >> I think the odds of it being a problem are small, but still it is >> a reserved word that shouldn't be reserved according to the SQL spec. > I suppose w

Re: [HACKERS] [patch] executor and slru dtrace probes

2009-12-23 Thread Zdenek Kotala
Greg Smith píše v út 15. 12. 2009 v 12:10 -0500: > Please send that updated version, and let's keep working on this into > the next CommitFest, where it will be in the front of the queue rather > than how it ended up at the tail of this one just based on its > submission date. You're not really

[HACKERS] win32env.c bug with no msvcrt

2009-12-23 Thread Magnus Hagander
There is code in src/port/win32env.c to update the environment within the msvcrt.dll runtime even when running in msvcr70.dll (visual C++ 2005). It updates that one, the local one *and* the system environment. However, in case there is no msvcrt.dll linked into the process, it will abort at that s

Re: [HACKERS] fdw validation function vs zero catalog id

2009-12-23 Thread Heikki Linnakangas
Martin Pihlak wrote: > I wrote: >> The validator is run for the generic options specified to CREATE/ALTER FDW, >> SERVER and USER MAPPING (+ possible future SQL/MED objects). In this case the >> catalog is always known. Also we can assume that the catalog is known, if a >> user >> runs the validat

Re: [HACKERS] creating index names automatically?

2009-12-23 Thread Greg Stark
On Wed, Dec 23, 2009 at 3:54 AM, Tom Lane wrote: > Alvaro Herrera writes: >> David E. Wheeler wrote: >>> +1 if it prevents indexes from being named "CONCURRENTLY". > >> Yeah, if you really want to have an index named like that you can use >> double quotes.  Seems a sensible compromise. > > Well,

Re: [HACKERS] Backup history file should be replicated in Streaming Replication?

2009-12-23 Thread Heikki Linnakangas
Tom Lane wrote: > Heikki Linnakangas writes: >> I think we could get away without the backup history file altogether. > > Hmmm ... actually I was confusing these with timeline history files, > which are definitely not something we can drop. You might be right > that the backup history file could

Re: [HACKERS] Tuplestore should remember the memory context it's created in

2009-12-23 Thread Heikki Linnakangas
Tom Lane wrote: > Heikki Linnakangas writes: >> But we don't use tuplesort to return tuples from functions, so it's not >> broken in a user-visible way. Unless you can think of another scenario >> like that. > > (1) create a cursor whose plan involves a sort that will spill to disk > (2) enter su