[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 platforms. But is that platform supported
for development anyway?
Hannes.
Index: src/tools/msvc/Install.pm
===
--- src/tools/msvc/Install.pm (revision 44)
+++ src/tools/msvc/Install.pm (working copy)
@@ -110,7 +110,7 @@
my $subdirs = $norecurse?'':'/s';
print Copying $what unless ($silent);
-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;
while ($D)
{
chomp;
@@ -375,7 +375,7 @@
print Installing NLS files...;
EnsureDirectories($target, share/locale);
-open($D,dir /b /s nls.mk|) || croak Could not list nls.mk\n;
+open($D,cmd /c dir /b /s nls.mk|) || croak Could not list nls.mk\n;
while ($D)
{
chomp;
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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 the Oid to name mapping exercise to populate the relevant fields in IndexStmt some of which are char pointers. The internal DefineIndex function also expects most of the fields to be in IndexStmt like format. If we want to follow the above suggestion, as I understand it, we might have to devise a new structure to contain Oids and make ProcessUtility accept a new nodeTag. We will also not be able to use existing Index definition functions and this will lead to more coding IMHO. Do we want to go down this path? Or is there something else that has been suggested above and that I am missing completely? OTOH, we can populate a new structure with the relevant Oids, IndexInfo information from parent relation indexes and call index_create directly from within ProcessUtility. Guess, it should be cleaner than the current approach. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
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 IndexStmt structure. That is why the current patch does all the Oid to name mapping exercise to populate the relevant fields in IndexStmt some of which are char pointers. The internal DefineIndex function also expects most of the fields to be in IndexStmt like format. If we want to follow the above suggestion, as I understand it, we might have to devise a new structure to contain Oids and make ProcessUtility accept a new nodeTag. We will also not be able to use existing Index definition functions and this will lead to more coding IMHO. Do we want to go down this path? Or is there something else that has been suggested above and that I am missing completely? OTOH, we can populate a new structure with the relevant Oids, IndexInfo information from parent relation indexes and call index_create directly from within ProcessUtility. Guess, it should be cleaner than the current approach. 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 remain. 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. IMHO, all this is less work and the bulk of the changes remain localized in mostly one or two functions as in the current patch. Comments? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
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 remain. 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. Sounds reasonable. This is what we do for example in VacuumStmt. Make sure that the OIDs are set to Invalid in the parser. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
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 best way to do this. If we need to recurse we should use File::Find. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
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 need to touch. The original suggestion was to actively refactor existing code, which might or might not have been worthwhile. But this isn't an appropriate substitute --- it's just making the API uglier for no particular benefit. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
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 patch to complicate parts of the system it didn't need to touch. The original suggestion was to actively refactor existing code, which might or might not have been worthwhile. But this isn't an appropriate substitute --- it's just making the API uglier for no particular benefit. 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 think converting the Oids to names is safe enough. Alvaro, do you think we should stick to the existing patch mechanism then considering that it avoids polluting the API? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
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 make-work that causes the patch to complicate parts of the system it didn't need to touch. The original suggestion was to actively refactor existing code, which might or might not have been worthwhile. But this isn't an appropriate substitute --- it's just making the API uglier for no particular benefit. 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 think converting the Oids to names is safe enough. Alvaro, do you think we should stick to the existing patch mechanism then considering that it avoids polluting the API? 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. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
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 LIKE INCLUDING INDEXES to a higher standard. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
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 think converting the Oids to names is safe enough. Alvaro, do you think we should stick to the existing patch mechanism then considering that it avoids polluting the API? 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. I doubt if accessMethod name will change. The tableSpace name can change, but the possibility is no worse to doing a [CREATE TABLE table_name ... TABLESPACE tablespace]. So this should be reasonably ok. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
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 previously there is an unrelated trivial hunk in here. I noticed we free the password early, presumably for security reasons, but don't actually overwrite the memory at that point. I added a memset in there, otherwise the free seems kind of pointless. I normally don't bother with security features like that since they don't really add any security but as long as it's there it may as well do something vaguely useful. Greg, In general this looks quite reasonable. It's a very large patch for a feature of this size, but luckily it's mostly changes due to the new pset structure rather than new code. There are some places that it doesn't use PG style (e.g. no newline before brace after if) and some comments that need to be fixed (e.g. /* XXX get result */ ) If you can fix that I'll apply the patch - I especially want to get it tested widely via the buildfarm. I am leaving town for about 5 or 6 days on Friday morning, and my availability will be somewhat restricted during that time, so if this isn't fixed pronto it will possibly have to wait till my return or till another reviewer takes pity on you :-) cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
