Re: pgScript patch
От | Magnus Hagander |
---|---|
Тема | Re: pgScript patch |
Дата | |
Msg-id | 48A1CC8A.6040000@hagander.net обсуждение исходный текст |
Ответ на | Re: pgScript patch ("Mickael Deloison" <mdeloison@gmail.com>) |
Список | pgadmin-hackers |
Mickael Deloison wrote: > 2008/8/12 Dave Page <dpage@pgadmin.org>: >> What you advocate there sounds to me like it should be integrated in >> the sense that it's part of our codebase, but isolated in it's own >> project and built as a DLL to be used by pgAdmin. Which in some ways >> gives us the best of both worlds, as Mickael could continue to >> maintain the code outside of the pgAdmin cycle, either directly on >> branches of the pgAdmin code, or by working on a copy from which we >> update the pgAdmin tree periodically. >> >> I actually kinda like that idea... > > At this time, when fully integrated into pgAdmin codebase, pgScript is > in pgadmin/include/pgscript and pgadmin/pgscript directories: so this > quite "isolated". > > But, for me, the big pro of having pgScript as a separate executable > (pgadmin3.exe and pgscript.exe) is that the operating system takes > care of cleaning pgScript mess when this last one exits: you cannot > have any memory leak or instability in pgAdmin because of a potential > bug in pgScript [ I hope there is none ;-), but at this time I have > some problems with the threads ]. > > I think a DLL is just a way of isolating pgScript a bit more but maybe > I'm wrong. Anyway, pgScript can be compiled as a static library > (lipbpgs.a). I do not know how to make a DLL (never done that) but I > guess it could be done quite easily since I can compile it as a static > library. It usually is. But if it's not bundled, a very clear interface has to be defined, and it's a contract you cannot violate easily. That's what causes DLL Hell... Which is one reason I like the tight integration. //Magnus
В списке pgadmin-hackers по дате отправления: