Обсуждение: pgScript patch based on pgScript-1.0-beta-3
Hi, There is a new patch for pgAdmin that includes pgScript. Maybe the crashes Dave and Guillaume got were caused by a simultaneous access to the output stream, which is now solved. This patch is based on r7403: * r7403-dif-pgs1.0b3.zip for the source code patch * r7403-bin-pgs1.0b3.zip for the Windows binary Everything is here: http://pgscript.projects.postgresql.org/pgadmin/ Please let me know your choice about how to integrate pgScript into pgAdmin (DLL, ...)? Best regards, Mickael
On Thu, August 14, 2008 02:00, Mickael Deloison wrote: > There is a new patch for pgAdmin that includes pgScript. Maybe the > Everything is here: http://pgscript.projects.postgresql.org/pgadmin/ Hi Mickael, I played a bit with pgScript; I like it. Here are a few observations: 1) It would be nice if pgScript would only execute a select-block, like the normal pgAdmin querytool does. 2) The example script from the url above says: IF (SELECT 1 FROM table) -- Then table exists which is only true if the table has rows, which of course initially it hasn't. This totally confounds the pgScript newbie ;-) Maybe it can be changed to: IF (SELECT count(*) FROM table) -- Then table exists Now it will NOT fail when table exist, but is empty. This will make the snippet executable with pressing repeated F6. 3) When the BEGIN - END block fails, pgScript executes the ELSE block. This seems questionable behaviour, no? It can be seen with that same above-mentioned script. (in the original 'IF (SELECT 1 FROM table)' form ) Great project - keep up the good work! Erikjan Rijkers
On Thu, Aug 14, 2008 at 1:00 AM, Mickael Deloison <mdeloison@gmail.com> wrote: > Hi, > > There is a new patch for pgAdmin that includes pgScript. Maybe the > crashes Dave and Guillaume got were caused by a simultaneous access to > the output stream, which is now solved. > > This patch is based on r7403: > * r7403-dif-pgs1.0b3.zip for the source code patch > * r7403-bin-pgs1.0b3.zip for the Windows binary > Everything is here: http://pgscript.projects.postgresql.org/pgadmin/ OK - I'll try to test this week but I'm pretty busy right now. > Please let me know your choice about how to integrate pgScript into > pgAdmin (DLL, ...)? Well a lot of the argument around separating it was based on the idea that you would continue to work on it without being bound by the pgAdmin release cycle. I think that makes you one of major the decision makers - so what do you think we should do? FWIW, I don't have any major objection to any of the integration methods, though having it as a completely separate executable is probably my least favourite option. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
2008/8/14 Dave Page <dpage@pgadmin.org>: > Well a lot of the argument around separating it was based on the idea > that you would continue to work on it without being bound by the > pgAdmin release cycle. I think that makes you one of major the > decision makers - so what do you think we should do? > > FWIW, I don't have any major objection to any of the integration > methods, though having it as a completely separate executable is > probably my least favourite option. > I'm not sure to understand all the possibilities. By DLL, what do you mean? Do you say that pgScript code would be on pgFoundry (like it is right now) or would be on pgAdmin SVN. If on pgAdmin SVN, would it be compiled and included in pgAdmin when you compile pgAdmin? And with a DLL, isn't there a problem if you want to distribute pgAdmin binary with the PostgreSQL Windows distribution? Because the DLL should be distributed as well... Mickael
On Thu, Aug 14, 2008 at 2:26 PM, Mickael Deloison <mdeloison@gmail.com> wrote: > I'm not sure to understand all the possibilities. > By DLL, what do you mean? Do you say that pgScript code would be on > pgFoundry (like it is right now) or would be on pgAdmin SVN. If on > pgAdmin SVN, would it be compiled and included in pgAdmin when you > compile pgAdmin? And with a DLL, isn't there a problem if you want to > distribute pgAdmin binary with the PostgreSQL Windows distribution? > Because the DLL should be distributed as well... Integrated: The source code is added as an integral part of the pgAdmin source tree, fully integrated. DLL: The source code is added as a shared library to the pgAdmin source tree. The main pgAdmin project then utilises that DLL. This allows the pgScript DLL to be used by other applications, and may be incrementally updated in branches within the SVN repository (we would obviously give you commit rights to do that). This would require some synchronisation of effort to ensure that you didn't change APIs in a way that would cause us problems (we'd manage that through some version numbering agreement). Separate: pgScript is maintained entirely outside of the pgAdmin source tree, either on pgFoundry, pgadmin.org, Google Code or whereever. You maintain it as you see fit, and we bundle your third party executable. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
2008/8/14 Dave Page <dpage@pgadmin.org>: > On Thu, Aug 14, 2008 at 2:26 PM, Mickael Deloison <mdeloison@gmail.com> wrote: > >> I'm not sure to understand all the possibilities. >> By DLL, what do you mean? Do you say that pgScript code would be on >> pgFoundry (like it is right now) or would be on pgAdmin SVN. If on >> pgAdmin SVN, would it be compiled and included in pgAdmin when you >> compile pgAdmin? And with a DLL, isn't there a problem if you want to >> distribute pgAdmin binary with the PostgreSQL Windows distribution? >> Because the DLL should be distributed as well... > > Integrated: > > The source code is added as an integral part of the pgAdmin source > tree, fully integrated. > > DLL: > > The source code is added as a shared library to the pgAdmin source > tree. The main pgAdmin project then utilises that DLL. This allows the > pgScript DLL to be used by other applications, and may be > incrementally updated in branches within the SVN repository (we would > obviously give you commit rights to do that). This would require some > synchronisation of effort to ensure that you didn't change APIs in a > way that would cause us problems (we'd manage that through some > version numbering agreement). > > Separate: > > pgScript is maintained entirely outside of the pgAdmin source tree, > either on pgFoundry, pgadmin.org, Google Code or whereever. You > maintain it as you see fit, and we bundle your third party executable. > So I talked with Magnus. The simplest solution is fully integrated because I designed pgScript to be fully integrated. A library is the most difficult one. Therefore we chose fully integrated with a possibility to deactivate pgScript with a ./configure option if it is not wanted. And also give the possibility to build pgScript.exe standalone executable in xtra/pgscript. Mickael
On Thu, Aug 14, 2008 at 4:22 PM, Mickael Deloison <mdeloison@gmail.com> wrote: > > So I talked with Magnus. The simplest solution is fully integrated > because I designed pgScript to be fully integrated. A library is the > most difficult one. > Therefore we chose fully integrated with a possibility to deactivate > pgScript with a ./configure option if it is not wanted. > And also give the possibility to build pgScript.exe standalone > executable in xtra/pgscript. Yeah, I chatted with Magnus as well. The conclusion we came to was to have pgScript built as a static library under somewhere like $SRC/pgscript-lib, with the CLI at $SRC/xtra/pgscript-cli/. They would both be implemented as additional projects within the solution in VC++, and as make targets on other platforms. The pgAdmin project would gain a dependency on pgscript-lib of course. Does that sound about right? BTW, don't bother with the configure switch. We only add them (and even then, extremely rarely) for fucntionality that might require additional external dependencies. Because pgScript will be integrated and can be ignored in the UI, I see no good reason to need to disable it. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page wrote: > On Thu, Aug 14, 2008 at 4:22 PM, Mickael Deloison <mdeloison@gmail.com> wrote: >> So I talked with Magnus. The simplest solution is fully integrated >> because I designed pgScript to be fully integrated. A library is the >> most difficult one. >> Therefore we chose fully integrated with a possibility to deactivate >> pgScript with a ./configure option if it is not wanted. >> And also give the possibility to build pgScript.exe standalone >> executable in xtra/pgscript. > > Yeah, I chatted with Magnus as well. The conclusion we came to was to > have pgScript built as a static library under somewhere like > $SRC/pgscript-lib, with the CLI at $SRC/xtra/pgscript-cli/. They would > both be implemented as additional projects within the solution in > VC++, and as make targets on other platforms. The pgAdmin project > would gain a dependency on pgscript-lib of course. > > Does that sound about right? We dumped the static library part, because that library would depend on pgadmin itself, and we'd either get duplicate symbols or a circular reference. (pgScript requires a few classes from pgAdmin to work) So we're back to linking directly with pgadmin. > BTW, don't bother with the configure switch. We only add them (and > even then, extremely rarely) for fucntionality that might require > additional external dependencies. Because pgScript will be integrated > and can be ignored in the UI, I see no good reason to need to disable > it. Ok. //Magnus
2008/8/14 Dave Page <dpage@pgadmin.org>: > On Thu, Aug 14, 2008 at 4:22 PM, Mickael Deloison <mdeloison@gmail.com> wrote: >> >> So I talked with Magnus. The simplest solution is fully integrated >> because I designed pgScript to be fully integrated. A library is the >> most difficult one. >> Therefore we chose fully integrated with a possibility to deactivate >> pgScript with a ./configure option if it is not wanted. >> And also give the possibility to build pgScript.exe standalone >> executable in xtra/pgscript. > > Yeah, I chatted with Magnus as well. The conclusion we came to was to > have pgScript built as a static library under somewhere like > $SRC/pgscript-lib, with the CLI at $SRC/xtra/pgscript-cli/. They would > both be implemented as additional projects within the solution in > VC++, and as make targets on other platforms. The pgAdmin project > would gain a dependency on pgscript-lib of course. > > Does that sound about right? > > BTW, don't bother with the configure switch. We only add them (and > even then, extremely rarely) for fucntionality that might require > additional external dependencies. Because pgScript will be integrated > and can be ignored in the UI, I see no good reason to need to disable > it. > It is not good because as we said, pgScript relies on pgadmin/db and pgadmin/utils stuff.
On Thu, Aug 14, 2008 at 4:34 PM, Magnus Hagander <magnus@hagander.net> wrote: >> Does that sound about right? > > We dumped the static library part, because that library would depend on > pgadmin itself, and we'd either get duplicate symbols or a circular > reference. > (pgScript requires a few classes from pgAdmin to work) > > So we're back to linking directly with pgadmin. Oh, OK - well I'm fine with that. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Hi Erikjan,
Here a few answers to your questions.
2008/8/14 Erikjan Rijkers <er@xs4all.nl>:
> 1) It would be nice if pgScript would only execute a select-block, like the
> normal pgAdmin querytool does.
Do you mean: redirecting a pgScript script to the regular query tool
if both the pgScript button is pressed and the edit window contains
only a select statement?
If this is case, I do not think it should be a good idea because
pgScript has its own behavior and it should not change whether there
is only one select statement or more in the edit window. Or maybe I
misunderstood your observation.
> 2) The example script from the url above says:
>
> IF (SELECT 1 FROM table) -- Then table exists
>
> which is only true if the table has rows, which of course initially it hasn't.
> This totally confounds the pgScript newbie ;-) Maybe it can be changed to:
>
> IF (SELECT count(*) FROM table) -- Then table exists
>
> Now it will NOT fail when table exist, but is empty.
>
> This will make the snippet executable with pressing repeated F6.
Ok, it was a mistake in the documentation. I just tested this kind of
script and if the query returns nothing or it fails then the result is
considered false.
You're right, with a count(*) it returns something (0 if no rows) and
this is true.
> 3) When the BEGIN - END block fails, pgScript executes the ELSE block. This
> seems questionable behaviour, no? It can be seen with that same
> above-mentioned script. (in the original 'IF (SELECT 1 FROM table)' form )
I do not understand this observation. Could you be more precise please?
I just bring some clarity on my side:
1) BEGIN and END are like { and } in C++. They enclose blocks but they
have nothing to do with transactions
(http://pgscript.projects.postgresql.org/SCRIPT.html#id4731518).
You must use BEGIN TRANSACTION and END TRANSACTION for transactions
otherwise it conflicts with pgScript.
2) When a query fails (syntax error, ...) it does not interrupt the
script. In this case you have a WARNING with the error message. In the
case the query is fine you have a NOTICE.
This script outputs 'table exists' if the table t1 actually exists and
then exits because of an assertion failure, but it does not execute
the else block.
if (select count(*) from t1)
begin
print 'table exists';
assert 0;
end
else
begin
print 'table does not exist';
end
In the "select count(*) from t1" in the above script is replaced with
a erroneous query "select count(*) fm t1" then you have a WARNING
because of the incorrect query and then it goes to the else block.
This is not really correct but except aborting the script I do not see
how I can do otherwise. Was this your observation?
Many thanks for your feedback,
Mickael
2008/8/14 Dave Page <dpage@pgadmin.org>: > On Thu, Aug 14, 2008 at 4:34 PM, Magnus Hagander <magnus@hagander.net> wrote: >>> Does that sound about right? >> >> We dumped the static library part, because that library would depend on >> pgadmin itself, and we'd either get duplicate symbols or a circular >> reference. >> (pgScript requires a few classes from pgAdmin to work) >> >> So we're back to linking directly with pgadmin. > > Oh, OK - well I'm fine with that. Hi, I uploaded my last patch. This patch includes: * pgScript fully integrated with pgAdmin code (pgadmin/include/pgscript and pgadmin/pgscript) * pgScript CLI, unit test suite, integration test suite and documentation in xtra/pgscript * Help page of the query tool updated and with the pgScript scripting language reference * Two pictures for the query tool help page * An option to ./configure (--disable-pgscript) to disable pgScript in pgAdmin (this does not work in VC++ of course) The patch: http://pgscript.projects.postgresql.org/pgadmin/r7403-dif-pgs1.0b4.zip Best regards, Mickael
On Sat, August 16, 2008 15:55, Mickael Deloison wrote: > 2008/8/14 Erikjan Rijkers <er@xs4all.nl>: >> 1) It would be nice if pgScript would only execute a select-block, like the >> normal pgAdmin querytool does. > > Do you mean: redirecting a pgScript script to the regular query tool > if both the pgScript button is pressed and the edit window contains > only a select statement? No. In the regular query tool one can draw a select block (with mouse or keyboard). Subsequently pressing F5 *only* executes the selected text. This is a very handy behaviour that (I think) could be mimicked by pgscript without problem. (it makes it easy to quickly test parts of a larger script.) >> 2) The example script from the url above says: >> IF (SELECT 1 FROM table) -- Then table exists > You're right, with a count(*) it returns something (0 if no rows) and > this is true. Right, thanks. >> 3) When the BEGIN - END block fails, pgScript executes the ELSE block. >> This >> seems questionable behaviour, no? It can be seen with that same > I do not understand this observation. Could you be more precise please? Upon consideration, I might have been mistaken; I'll test again and look for a clearly reproducible case. thanks, Erikjan
2008/8/16 Erikjan Rijkers <er@xs4all.nl>: > No. > > In the regular query tool one can draw a select block (with mouse or > keyboard). Subsequently pressing F5 *only* executes the selected text. This > is a very handy behaviour that (I think) could be mimicked by pgscript without > problem. > (it makes it easy to quickly test parts of a larger script.) > All right. I need to stop the development of pgScript until it is approved (and I hope integraed) by pgAdmin. But then I put that as the first item of the TODO list.
On Sat, Aug 16, 2008 at 4:07 PM, Mickael Deloison <mdeloison@gmail.com> wrote: > Hi, > > I uploaded my last patch. This patch includes: > * pgScript fully integrated with pgAdmin code > (pgadmin/include/pgscript and pgadmin/pgscript) > * pgScript CLI, unit test suite, integration test suite and > documentation in xtra/pgscript > * Help page of the query tool updated and with the pgScript > scripting language reference > * Two pictures for the query tool help page > * An option to ./configure (--disable-pgscript) to disable pgScript > in pgAdmin (this does not work in VC++ of course) > The patch: http://pgscript.projects.postgresql.org/pgadmin/r7403-dif-pgs1.0b4.zip Hi Mickael, That's excellent - thanks. Congratulations on completing your GSoC project! I'll work with Magnus now to get the patch integrated and committed (he's leading that work, as I'll be doing Luis'). Go get yourself a nice cold beer or three to celebrate :-) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com