[PATCHES] msvc, build and install with cygwin in the PATH

With a small modification to src/tools/msvc/Install.pm (see attached patch) it's possible for me to build with msvc and install postgres on a Windows xp box and leave cygwin in the PATH. Since I use cygwin frequently it's usfull for me to have it in the PATH. This might not work on Win9x

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, The index creation happens after the new table (which is LIKE the parent) has been created, by appending the cxt.alist information to extras_after. The entry point for the index creation is thus via ProcessUtility which expects an IndexStmt structure. That is why the current patch does all

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, On 5/23/07, NikhilS [EMAIL PROTECTED] wrote: Hi, The index creation happens after the new table (which is LIKE the parent) has been created, by appending the cxt.alist information to extras_after. The entry point for the index creation is thus via ProcessUtility which expects an

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

NikhilS escribió: Sorry for the barrage of emails. But as I looked closely at the current patch there are only 2 fields (accessMethod and tableSpace) in IndexStmt structure that we populate by doing the conversion from OIDs to name. For the other fields, the current transformations will

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Hannes Eder wrote: -open($D, dir /b $subdirs $spec |) || croak Could not list $spec\n; +open($D, cmd /c dir /b $subdirs $spec |) || croak Could not list $spec\n; What the heck are we doing here anyway? We should be doing this a la Perl - calling out to dir /b is surely not the

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

NikhilS [EMAIL PROTECTED] writes: If so, I think we can introduce 2 Oid fields in the IndexStmt structure and store the Oids there. In DefineIndex we can use these Oids if they are not invalid. I think this is just make-work that causes the patch to complicate parts of the system it didn't

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, On 5/23/07, Tom Lane [EMAIL PROTECTED] wrote: NikhilS [EMAIL PROTECTED] writes: If so, I think we can introduce 2 Oid fields in the IndexStmt structure and store the Oids there. In DefineIndex we can use these Oids if they are not invalid. I think this is just make-work that causes the

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

NikhilS escribió: On 5/23/07, Tom Lane [EMAIL PROTECTED] wrote: NikhilS [EMAIL PROTECTED] writes: If so, I think we can introduce 2 Oid fields in the IndexStmt structure and store the Oids there. In DefineIndex we can use these Oids if they are not invalid. I think this is just

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Alvaro Herrera [EMAIL PROTECTED] writes: Not sure. Is it possible that the schema is renamed while the operation is being executed? If it's not then this not a problem at all so the existing patch is fine. There are hazards of that type in CREATE TABLE right now; it's hardly fair to hold

Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

Hi, I agree this will unnecessary add arguments to the DefineIndex API. If we stick to the patch's earlier way of converting the Oid to names for just these 2 arguments, we can avoid this IMO. Considering that we will be generating this information from existing valid index information, I

Re: [PATCHES] Concurrent psql patch

Gregory Stark wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Gregory Stark wrote: Attached is an updated patch. This patch appears to add a nonexistent test to the regression schedules. I must have forgotten to cvs add it. Sorry. Also, I forgot to mention