On 10 December 2013 19:55 Alvaro Herrera wrote: > Haribabu kommi escribió: > > > To detect provided data and xlog directories are same or not, I > reused > > the Existing make_absolute_path() code as follows. > > > > 1. Moved the make_absolute_path() function from miscinit.c to path.c > > and Changed all error reporting functions. And also it returns NULL > > incase of any error. > > > > 2. Added a new file called fe_path.c which contains > > make_absolute_path() only for frontend code. > > Whatever you do, please don't add #include lines to postgres_fe.h. Add > them to whatever .c files that need to include the new header, instead. > (This results in a longer patch, yes, but that consideration shouldn't > drive anything. There is a desire to include as less headers as > possible in each source file, and adding more include lines to > postgres_fe.h means the new header will be included by every single > frontend file, even those not in core.) > > See a nearby patch by Bruce Momjian to deal with getpwnam() and > getpwuid() failures; perhaps the idea of returning an error string > should be designed similarly in both these patches. Also consider > using the psprintf stuff, which works on both backend and frontend, > avoiding malloc etc so that code can be shared by both frontend and > backend, eliminating the duplicity.
The make_absolute_path() function moving to port is changed in similar way as Bruce Momjian approach. The psprintf is used to store the error string which Occurred in the function. But psprintf is not used for storing the absolute path As because it is giving problems in freeing the allocated memory in SelectConfigFiles. Because the same memory is allocated in a different code branch from guc_malloc. After adding the make_absolute_path() function with psprintf stuff in path.c file It is giving linking problem in compilation of ecpg. I am not able to find the problem. So I added another file abspath.c in port which contains these two functions. Updated patches are attached in the mail. Please provide your suggestions. Regards, Hari babu.
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers