Re: [PATCHES] Fix ecpg SQL CONNECT with variable user name
On Fri, Dec 28, 2007 at 11:43:49AM +0900, ITAGAKI Takahiro wrote: Here is a fix for ecpg in 8.3 when the user name is specified by variables on SQL CONNECT. ... Just committed fix to CVS. Thanks for pointing this out and fixing it Takahiro-san. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(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] ecpg DllMain fix
On Wed, Oct 03, 2007 at 11:54:44AM +0900, ITAGAKI Takahiro wrote: Here is a patch to remove DllMain from libecpg on Win32 build. I brought the initialization routine from libpq and implemented pthread_once() using a lock that serializes all pthread_once calls. I don't have msvc build environment, but I hope it will fix the build failure on it. We will see. Since it doesn't break my linux system I committed the patch. If anyone notices a problem please tell me. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 04:07:06PM -0400, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Michael Meskes wrote: So, does an explicit export list help? If so I'm all for it. There is no need to export all symbols. I always tried to keep the number of symbols that get exported but are not needed low. So this will give the best result possible. Yeah, it does seem to fix it. That's very good news. If Michael can put together an export list soon then we'll be in good shape. I will work on it asap. Michael: you should bump the major version number of ecpglib when you do this. Removing the not-officially-exported visible symbols *is* an ABI break. You may think there isn't anything depending on them, but remember how we thought that (twice) for libpq too. Bumping the major version number will be cheap insurance against complaints later. ecpg received a bump from 5 to 6 in this release anyway because of some other ABI changes, so at least here we're fine. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 11:13:27AM +0200, Magnus Hagander wrote: Heh, I was about to review that. I'll try to get to it right after lunch. Thanks and sorry for jumping the gun. If it doesn't work we can remove it easily. I'm working on an export list atm. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 12:22:41PM +0200, Magnus Hagander wrote: It passes compile. Rebuilding my full tree now to try to work on making the regression tests actually be able to test it. Sounds good. :-) I'm working on an export list atm. Good. I think we want that regardless of things being fixed by removing Dllmain. Just committed. I also renamed the functions that are not exported to make this job easier. Should there be a problem with this it should only be a missed rename. However the new sources successfully run through the regression suite on my Linux system with and without multithreading. As for the export list I copied the stuff from libpq, it's untested on all other archs. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 02:27:20PM +0200, Magnus Hagander wrote: However, shouldn't we be doing it for other ECPG libraries as well? Done. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 02:38:09PM +0900, ITAGAKI Takahiro wrote: Here is a patch to fix thread-safety of SQL DESCRIPTOR in ecpg. ... Applied to CVS HEAD. Thanks. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 10:39:40AM -0400, Tom Lane wrote: I am very nearly ready to demand that ecpg as a whole be reverted to its state as of Saturday, with all the patches since then held for 8.4 development. At no point since Sunday morning has ecpg been passing If we say ecpg is not multithreaded I agree that these patches are features, but if we see it as multithreaded the patches are bug fixes. buildfarm testing, and I see no activity indicating that it's about to Magnus, correct me if I'm wrong, but it appears to me that the MSVC build problem has existed for weeks or months but no one noticed so far, right? It doesn't help to revert the patches if we still do not compile cleanly on MSVC. Or is it only the DLLMAIN thing that's holding us up? If so couldn't we just remove this function and call MSVC build not multithreaded? Also Takahiro (hope this is your first name :-)), could you please explain to us why DllMain is needed at all? it isn't needed on non-Windows systems it seems. As far as fixing things you're right. We need to fix this asap. get fixed. You guys are holding up beta release with work that by any legitimate definition is new-feature development, and shouldn't be under consideration at all at this point. As I said, I considered this work bug fixes or else I wouldn't have committed the patches at this time. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 12:53:58PM -0400, Andrew Dunstan wrote: It it appears to me that the MSVC build problem has existed for weeks or months but no one noticed so far, right? This is absolutely not true. We have been building ecpg successfully on MSVC all along, just not testing. See for example the make log at http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=red_batdt=2007-09-30%20043002stg=make and search for Project: libecpg Sorry, my bad. Seems I got this mixed up. Once we enabled testing for ecpg we had some problems to be sorted out, but right now only the DllMain thing seems to be a problem. Since I do not know whether we really need DllMain could anyone please test whether ecpg builds correctly without it? We can then sort out how to fix the problem later on. AFAIRC (and hopefully I'm right this time) multithreading never worked under msvc so we might have to set thread-safety to disabled on these systems for ecpg for the time being. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 08:23:21PM +0200, Magnus Hagander wrote: test that a build passes, but remember that we can't really run the regression tests on msvc right now :-( But then we definitely need to fix this, regardless of the DllMain thing. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 02:37:40PM -0400, Tom Lane wrote: AFAIRC (and hopefully I'm right this time) multithreading never worked under msvc so we might have to set thread-safety to disabled on these systems for ecpg for the time being. If it didn't work then this seems clearly new-feature-development. Well, ecpg was said to work with multithreading but didn't. However, since the patch works on most archs if indeed fixes some bugs on those archs. I think Magnus' idea of providing an exports list would be worth trying, if someone can try it promptly; failing that, we need to revert this patch. Couldn't we just disable multithreading for Windows resp. MSVC? It appears to me that the rest of the patch is working as advertized. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 08:22:21PM +0200, Magnus Hagander wrote: There are two problems: 1) DllMain breaks the build *completely*. This is the really urgent one. This one broke 2 days ago or so. 2) Regression tests don't pass on MSVC anymore. This broke a while ago. I was working on fixing this, but now that the build is broken there isn't much I can do until that's fixed. When did they break? I'm still confused. Did we run regression tests at all before? Or did they never work and we just didn't notice because the buildfarm didn't run them? Also, see http://archives.postgresql.org/pgsql-hackers/2007-10/msg6.php for another comment on this. This changes more than just the threading stuff, but if it's something we want then this is a good time to do it. So, does an explicit export list help? If so I'm all for it. There is no need to export all symbols. I always tried to keep the number of symbols that get exported but are not needed low. So this will give the best result possible. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] ecpg thead-safe memory management + cleanup
On Fri, Sep 28, 2007 at 03:00:54PM +0900, ITAGAKI Takahiro wrote: Here is a patch to get memory management to thread-safe. The auto_allocs global variable is split into per-thread variables and accessed separately in each thread. Thanks. Committed to CVS HEAD. * Release all prepared statements on disconnection to avoid memory leaks even if users forget to DEALLOCATE their statements before disconnection. Oops, should have noticed this. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Thread-safe PREPARE in ecpg
On Wed, Sep 26, 2007 at 01:43:34PM +0900, ITAGAKI Takahiro wrote: Here is a revised patch against CVS HEAD. I fixed a bug in ECPGdeallocate_all(). Applied to CVS HEAD. I also added your example to the regression tests. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] Thread-safe PREPARE in ecpg
On Tue, Sep 25, 2007 at 03:22:13PM +0900, ITAGAKI Takahiro wrote: Here is a WIP patch to make prepared statements thread-safe in ecpg. The variable prep_stmts was global but not protected by any locks. I divided it into per-connection field so that we can access prepared statements separately in each thread. Thanks a lot. This is exactly how I was planning to implement it, but I haven't even found the time to start coding yet. :-) Could you please create a small example that we could add to the regression suite? I needed to change the following exported functions, but it will introduce an incompatibility issue. It might be ok for CVS HEAD, but I'd like to port the fix to back versions. Do you have any thoughts on how we can accomplish this better? No idea at the moment, sorry. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Regression tests
On Tue, Jun 12, 2007 at 01:16:32PM +0200, Magnus Hagander wrote: I have applied a fairly well reworked version of this. The big thing is that I moved the building of the pgc code out of the regression test driver and into the build system using msbuild. I also did a couple of minor fixes to the threading tests and such. Thanks. It seems you missed one file. make checktcp says: pg_regress: could not open file ./ecpg_schedule_tcp for reading Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Patch needed fot dt.h
On Mon, May 21, 2007 at 10:17:30AM -0400, Tom Lane wrote: I'm wondering why the back-branch patches added a dependency on DTK_ISODOW in the first place. That looks more like a copypaste error than something intentional. Michael? It is, somehow it slipped through. Just removed it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ECPG patch to use prepare for improved performance
On Wed, May 09, 2007 at 01:12:17PM -0700, William Lawrance wrote: 2. The performance was improved by about 1 hour in the 3 hour elapsed time of the application. This is important to the customer in terms of accomplishing his work load in the time that has been allotted, based on his experience with DB2. Without this improvement, he is likely to consider it too slow. But this only holds for one customer. I don't think this will hold for every single application. At least I do not see a reason why this should hold everytime. I would like to emphasize that we aren't measuring an artificial test program; this is a real customer's application. We loaded 7 million rows into 217 tables to run the application. I believe it is representative of many real batch applications. But how about non-batch applications? Is there reason not to prepare each statement? I'm completely against forcing such a design decision on the programmer. Hopefully I will be able to add a real prepare statement soon. Could it be predicated upon a user supplied option ? Yes, this is fine with me. If you could rearrange the patch I will test and commit it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] ECPG patch to use prepare for improved performance
On Mon, May 07, 2007 at 02:46:29PM -0700, William Lawrance wrote: This patch for ECPG utilizes the PQprepare and PQexecPrepared functions to cause SQL statements from ECPG to be cached. It does this without requiring any changes in the user's source program. ... I still do not understand why you prepare each statement. This might help you with your test case, but I don't like to add this as a general rule. If a user wants a prepared statement he/she should use the prepare statement. I agree that the prepare logic has to be rewritten and this is high on my agenda, but I will probably only do this for statements issued with EXEC SQL PREPARE not for every single statement. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ecpg threading vs win32
On Mon, Apr 02, 2007 at 09:06:17PM -0400, Bruce Momjian wrote: Michael, is there any progress on this? --- So this essantially is only to get an error message into the connection structure. However, having an empty connection makes PQescapeStringConn return an error and an empty string which I consider a problem. I have to check that in detail but we may run into a usage of PQescapeString without an open connection which then would fail. Not really. IMO it should remain as it is. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] ecpg threading vs win32
On Mon, Mar 19, 2007 at 09:48:19AM +0100, Magnus Hagander wrote: Q2. Do we need to use PQescapeStringConn() instead of PQescapeString()? PQescapeString() is used to escape literals, and the documentation says PQescapeStringConn() should be used in multi-threaded client programs. http://momjian.us/main/writings/pgsql/sgml/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING | PQescapeString can be used safely in single-threaded client programs | that work with only one PostgreSQL connection at a time Seems so, but that's unrelated to this patch ;-) I'll leave the final comment on that up to Michael. Looking at the source code it seems to me that the connection argument is only used once in PQescapeStringInternal which both functions call. Here's the snippet: if (conn) printfPQExpBuffer(conn-errorMessage, libpq_gettext(incomplete multibyte character\n)); So this essantially is only to get an error message into the connection structure. However, having an empty connection makes PQescapeStringConn return an error and an empty string which I consider a problem. I have to check that in detail but we may run into a usage of PQescapeString without an open connection which then would fail. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] patch for ECPG (BUG #2956: ECPG does not treat multibyte characters correctly.)
On Tue, Feb 27, 2007 at 08:51:36PM +0900, ITAGAKI Takahiro wrote: I tested the change and it worked fine, but I found that this fix Good to hear. should be backported -- it might cause SQL injections depending on I absolutely agree, that's why I just committed your patches. :-) Thanks for your effort. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] patch for ECPG (BUG #2956: ECPG does not treat multibyte characters correctly.)
On Fri, Feb 09, 2007 at 05:29:21PM +0900, 原田登志 wrote: I found bug in ecpg concerning processing of the multi-byte character-code. I reported as bug#2956 before. Thanks for report and patch. Attached is the patch to fix this problem. This patch is against 8.1, right? I had to apply it manually to HEAD, so I might have made some error here. Also I don't see why we have to add the connection to all thos function calls, just to make sure we get an error message logged in the connection struct that apparently isn't evaluated anyway. Please correct me if I'm wrong on this one. I'm just committing the changes to CVS but only to HEAD because I cannot check if my changes broke something. The sources work fine on my system and the regression tests pass without a problem. But then I do not have a setup similar to yours. Could you please test this? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] ECPG docs
On Mon, Dec 04, 2006 at 10:33:47AM -0500, Chris Browne wrote: I noticed the following error in the chapter on ECPG... ... - The preprocessed file can be compiled normally, for example: + The processed file can be compiled normally, for example: I beg to disagree. ECPG is an embedded SQL preprocessor, so why can't the file be called preprocessed? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ECPG docs
On Mon, Dec 04, 2006 at 12:40:28PM -0500, Chris Browne wrote: The other option I was thinking of was postprocessed, because the .c file comes *after* processing. Well, the .c file is the one that should be processed. So you have to preprocess the .pc file to get a .c file. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] BUG #2741: Double-free on error in ECPGconnect
On Tue, Nov 07, 2006 at 02:31:57PM +, Peter Harris wrote: Attached is a patch to make ECPGconnect call ECPGclear_auto_mem, as ECPGdo already does. Thanks. I applied the patch to CVS HEAD, 8.1 and 8.0. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] Interval month, week - day
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
When I tried the ecpg regression tests it complained there was no
results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The pg_regress.sh has this code that
should create it:
outputdir=results/
if [ ! -d $outputdir ]; then
mkdir -p $outputdir || { (exit 2); exit; }
fi
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] Changes to epgc test
On Tue, Aug 29, 2006 at 02:46:06PM -0400, Chris Browne wrote: I'm not at all sure that these are the right changes to apply; it somewhat appears to me as though ecpg is supposed to be able to cope with the omissions. Yor're right. It should cope with those. The database names were ommitted by design. It seems to me that it is working on the few buildfarm machines that have it enabled so far. Mabye you still had an old preproc.y/preproc.c around? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ECPG regress tests fix for VPATH builds
On Sat, Aug 12, 2006 at 03:35:12PM -0400, Alvaro Herrera wrote: This patch allows ECPG to build on a VPATH build. I didn't commit it just because I don't have a non-VPATH build to make sure it still works ... Worked for me on a normal build too. Applied. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [PATCH] 4 coverity patches for ECPG
On Sun, Apr 23, 2006 at 11:55:03PM +0200, Martijn van Oosterhout wrote: Here's some patches to clear up some of the most obvious problems with ECPG. This is just scratching the surface, but it's good to start somewhere: ... I just committed all patches to ecpglib. Sorry for the delay but it appears I haven't been subscribed to -patches. Now I am. The changes to the test directory weren't committed because the SoC work includes bringing those tests into the regression system, so I don't want to change the code base during that work. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [INTERFACES] [BUGS] BUG #2171: Differences compiling plpgsql in ecpg and psql
Actually ecpg should not translate dollar quoting at all. I'm going to fix this. Dollar quotes will then be send to the backend with translation and the backend takes care of the rest. Well, CVS version before I modified it had dolq stuff in the lexer to handle dollar quotes and pass it as SCONST to the parser. Yes, I know. This was buggy from the get go on IMO. :-) Not sure, but there appears to be a bug in the routine that outputs a statement. I will change that one as well and would ask you to just check again. It seems to me that this also fixes your problem. I tried with the one test case in this email and it seems to work. But then I'm currently travelling and do not have that much spare time to test. The problem is that output.c does: printf(abc def); While some compilers are OK with that, others are not. I changed it to output: printf(abc\n\ def); Okay, will look into this again. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [INTERFACES] [BUGS] BUG #2171: Differences compiling plpgsql in ecpg and psql
On Wed, Feb 01, 2006 at 11:48:45PM -0500, Bruce Momjian wrote: I have researched your report, and you are right, there are two ecpg bugs here. First, dollar quoting uses single-quotes internally to do the quoting, but it does not double any single-quotes in the dollar-quoted string. Actually ecpg should not translate dollar quoting at all. I'm going to fix this. Dollar quotes will then be send to the backend with translation and the backend takes care of the rest. Second, when a dollar quoted string or single-quoted string spans multiple lines, ecpg does not escape the newline that is part of the string. Some compilers will accept an unescaped newline in a string, while others will not: Not sure, but there appears to be a bug in the routine that outputs a statement. I will change that one as well and would ask you to just check again. It seems to me that this also fixes your problem. I tried with the one test case in this email and it seems to work. But then I'm currently travelling and do not have that much spare time to test. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Add missing const qualifier in ECPG
I just applied most of your patch to 8.0, 8.1 and HEAD. The only thing I
didn't is:
diff -c -r1.7 memory.c
*** ecpglib/memory.c15 Oct 2005 02:49:47 - 1.7
--- ecpglib/memory.c16 Nov 2005 00:40:57 -
***
*** 11,17
void
ECPGfree(void *ptr)
{
! free(ptr);
}
char *
--- 11,18
void
ECPGfree(void *ptr)
{
! if (ptr)
! free(ptr);
}
char *
Is there a reason why you changed this? Acocrding to the docs free(NULL)
does nothing anyway.
Also you mentioned:
...
seems we allow strdup() fails silently in various
places. Shall we do something about it?
...
Yes! Thanks for pointing this out. I already committed a patch that
changes alls strdup() calls to ECPGstrdup() calls that correctly raise
an error condition.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR
On Thu, Oct 13, 2005 at 09:53:14PM -0400, Bruce Momjian wrote: Good catch! I have backpatched these fixes to the 8.0 and 7.4 branches as you suggested, (identical) patches attached. Thanks Bruce. This was an oversight on my part. I should have committed to 8.0 branch too. I'm sorry about that. On the other hand I agree with Tom. Fortunately it's not a data corruption problem. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [INTERFACES] [HACKERS] ECPG ignores SAVEPOINT if first statement of a transaction
On Sat, Aug 13, 2005 at 09:01:45AM -0600, Michael Fuhr wrote: If no statements have been executed in this transaction then committed is true, so ECPGtrans() ignores the current statement. It looks like the code should make an extra consideration for SAVEPOINT in case it's the first statement. I rearranged the whole code as it seemed to have more holes. This code really was old. :-) So could you please check with the lates CVS, either HEAD or 8.0? I'm also wondering if the check for a NULL return value from PQexec() is sufficient. Shouldn't it also check for a non-NULL result that's anything other than PGRES_COMMAND_OK? Yes, it should. I changed this as well. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] ECPG - Remove need for AT connection when using threads
On Sun, Mar 07, 2004 at 09:43:31PM -, Lee Kindness wrote: Attached diff improves the handling of connections in ecpg when threading is used. The current connection is now the last connection made/set for the I just applied this patch and the last one. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] ECPG - Remove need for AT connection when using threads
On Sun, Mar 14, 2004 at 09:11:27AM -0500, Bruce Momjian wrote: I just applied this patch and the last one. I assume you mean you applied: Update tests memory leak fix and ECPG - Remove need for AT connection when using threads Yes. Sorry, should have said so. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 8: explain analyze is your friend
