[pgadmin-hackers] pgAdmin III commit: PostgreSQL 8.5 was renamed 9.0
PostgreSQL 8.5 was renamed 9.0 Fix a couple of incorrect comments Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=17598151cbdd6bc7dc29bd36eb53b1cf0e9510b6 Modified Files -- pgadmin/include/debugger/dbgConnProp.h |2 +- pgadmin/schema/pgRole.cpp |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Email notification pgAgent
Hi On Tue, Dec 28, 2010 at 1:54 AM, Jasmin Dizdarevic wrote: > Okay, I'm almost done. Actually there is a problem with building the wxSMTP > package, so it doesn't send mails yet. > If this is done, I'm going to test it on Windows and *nix. Ok. > Time to take care about some other things: > 1. I'm coding on Windows with VS 2010. I've downloaded the source files and > run cmake to get a VS-Project. Here i made the changes. How I can generate a > patch file with git now, because I'm not working on the original source > files - because of the cmake step? Have I to redo the changes on *nix? You need to update the CMakeLists.txt file from which the VC++ project file and *nix build files are generated. > 2. What steps are necessary to send the changes to the community? Is there a Just send a patch (git diff) to pgadmin-hack...@postgresql.org. > desired process and what's about the necessary changes in the pgAdmin UI? > Will they be done by the maintainer of pgAdmin? Of course I'm ready to > participate in pgAdmin too, but my knowledge of C++ and wx are limited, so I > can not promise best quality ;) The maintainers of pgAdmin are the same people, and no, they won't automatically update the UI for the new feature I'm afraid (they have enough work to do just keeping up with changes in PostgreSQL). Please give it a try yourself, and we can help you iron out any kinks or issues you may run into. Regards, Dave -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] Keywords files
We haven't updated the keywords.cpp file for ages. In fact, so long ago that the instructions are incorrect. Recent versions of postgresql installs the list of keywords in kwlist.h. That requires PostgreSQL 8.4 or later. How old versions of the PostgreSQL *source* do we accept building against? Couldn't we just switch to using this include file instead, thus saying you need 8.4 or later to build? (it should still *run* against earlier versions just fine..) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Keywords files
On Wed, Dec 29, 2010 at 11:54 AM, Magnus Hagander wrote: > We haven't updated the keywords.cpp file for ages. In fact, so long > ago that the instructions are incorrect. > > Recent versions of postgresql installs the list of keywords in > kwlist.h. That requires PostgreSQL 8.4 or later. > > How old versions of the PostgreSQL *source* do we accept building > against? Couldn't we just switch to using this include file instead, > thus saying you need 8.4 or later to build? (it should still *run* > against earlier versions just fine..) Iirc, we need 8.3 (or whichever version included pgconninfoparse). I'm fine with moving to using the new include file - iirc, most distros have an 8.4 build now. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Keywords files
On Wed, Dec 29, 2010 at 14:55, Dave Page wrote:
> On Wed, Dec 29, 2010 at 11:54 AM, Magnus Hagander wrote:
>> We haven't updated the keywords.cpp file for ages. In fact, so long
>> ago that the instructions are incorrect.
>>
>> Recent versions of postgresql installs the list of keywords in
>> kwlist.h. That requires PostgreSQL 8.4 or later.
>>
>> How old versions of the PostgreSQL *source* do we accept building
>> against? Couldn't we just switch to using this include file instead,
>> thus saying you need 8.4 or later to build? (it should still *run*
>> against earlier versions just fine..)
>
> Iirc, we need 8.3 (or whichever version included pgconninfoparse). I'm
> fine with moving to using the new include file - iirc, most distros
> have an 8.4 build now.
That turned out to be a bit more work than I thought, mainly because
there were EnterpriseDB and Greenplum keywords included in the pgadmin
list - which was only documented in one of the two places where they
occurred :-)
Anyway, attached is a patch that I believe does this right. If you
prefer an easier view, see
https://github.com/mhagander/pgadmin3/compare/master...keywords
Does this look ok?
It does move the keyword definitions out of the header and into
keywords.cpp - but they aren't used anywhere.. So in general, I'm
fairly confident with it...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/pgadmin/db/keywords.c b/pgadmin/db/keywords.c
index 0c0f8b0..6ddf381 100644
--- a/pgadmin/db/keywords.c
+++ b/pgadmin/db/keywords.c
@@ -15,11 +15,9 @@
///
//
-// pgAdmin note: This file is based on src/backend/parser/keywords.c from
-// PostgreSQL. It should be periodically updated to include
-// new keywords. The ScanKeywords array and the definition
-// of ScanKeywordLookup are all that are required here - when
-// updating, ensure that no unecessary includes are added.
+// pgAdmin note: This file is based on src/backend/parser/keywords.c and
+// src/backend/parser/kwlookup.c from PostgreSQL, but extended
+// to support EntepriseDB and Greenplum.
//
// This file is under the BSD licence, per PostgreSQL.
///
@@ -28,429 +26,85 @@
#include "parser/keywords.h"
/*
+ * Load the yytokentype list of symbols from PostgreSQL
+ */
+#undef YYTOKENTYPE
+#include
+
+/*
+ * For non-PostgreSQL types, define an enumb with their values here
+ * NOTE! Make sure the value doesn't conflict with what's in
+ * server/parser/gram.h - as the PostgreSQL parser grows larger the
+ * highest numbers will increase.
+ */
+enum yytokentype_extra {
+ /* The following additions are keywords in EnterpriseDB */
+ CONNECT_EDB = 800,
+ CONVERT_EDB = 801,
+ MINUS_EDB = 802,
+ NUMBER_EDB = 803,
+ PACKAGE_EDB = 804,
+ SMALLDATETIME_EDB = 805,
+ SMALLFLOAT_EDB = 806,
+ SMALLMONEY_EDB = 807,
+ TINYINT_EDB = 808,
+ TINYTEXT_EDB = 809,
+ VARCHAR2_EDB = 810,
+ EXEC_EDB = 811,
+ LONG_EDB = 812,
+ NOCACHE_EDB = 813,
+ PLS_INTEGER_EDB = 814,
+ RAW_EDB = 815,
+ RETURN_EDB = 816,
+ SYSDATE_EDB = 817,
+ SYSTIMESTAMP_EDB = 818,
+
+ /* The following additions are keywords in Greenplum Database */
+ DISTRIBUTED_GP = 900,
+ LOG_P_GP = 901
+};
+
+
+/*
* List of (keyword-name, keyword-token-value) pairs.
+ */
+#define PG_KEYWORD(a,b,c) {a,b,c},
+const ScanKeyword ScanKeywords[] = {
+#include
+};
+const int NumScanKeywords = lengthof(ScanKeywords);
+
+/*
+ * Additional pairs here. They need to live in a separate array since
+ * the ScanKeywords array needs to be sorted!
*
* !!WARNING!!: This list must be sorted, because binary
- * search is used to locate entries.
+ * search is used to locate entries.
*/
-static const ScanKeyword ScanKeywords[] = {
- /* name, value, category */
- {"abort", ABORT_P, UNRESERVED_KEYWORD},
- {"absolute", ABSOLUTE_P, UNRESERVED_KEYWORD},
- {"access", ACCESS, UNRESERVED_KEYWORD},
- {"action", ACTION, UNRESERVED_KEYWORD},
- {"add", ADD_P, UNRESERVED_KEYWORD},
- {"admin", ADMIN, UNRESERVED_KEYWORD},
- {"after", AFTER, UNRESERVED_KEYWORD},
- {"aggregate", AGGREGATE, UNRESERVED_KEYWORD},
- {"all", ALL, RESERVED_KEYWORD},
- {"also", ALSO, UNRESERVED_KEYWORD},
- {"alter", ALTER, UNRESERVED_KEYWORD},
- {"always", ALWAYS, UNRESERVED_KEYWORD},
- {"analyse", ANALYSE, RESERVED_KEYWORD}, /* British spelling */
- {"analyze", ANALYZE, RESERVED_KEYWORD},
- {"and", AND, RESERVED_KEYWORD},
- {"any", ANY, RESERVED_KEYWORD},
- {"array", ARRAY, RESERVED_KEYWORD},
- {"as", AS, RESERVED_KEYWORD},
- {"asc", ASC, RESERVED_KEYWORD},
- {"assertion", ASSERTION, UNRESERVED_KEYWORD},
- {"assignment", ASSIGNMENT, UNRESERVED_KEYWORD},
- {"asymmetric", ASYMMETRIC, RESERVED_KEYWORD},
- {"at", AT, UNRESERVED_KEYWORD},
- {"authorization", AUTHORIZATION, TYPE_FUNC_NAME_KEYWORD},
- {"autov
[pgadmin-hackers] fix: cannot build wxWidgets if sources are located at another disk
For example, configuration wxWidgets sources are here: C:\libs\wxWidgets-2.8.11 PgAdmin sources are here: T:\my\pgadmin3 when in console I go to the "T:\my\pgadmin3\xtra\wx-build\" directory and run "build-wxmsw.bat", build fails. This patch fixes this. -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] fix: cannot build wxWidgets if sources are located at another disk
Sorry, forgot to attach the patch :-) 2010/12/29 Nail Samatov : > For example, configuration wxWidgets sources are here: > C:\libs\wxWidgets-2.8.11 > PgAdmin sources are here: > T:\my\pgadmin3 > > when in console I go to the "T:\my\pgadmin3\xtra\wx-build\" directory > and run "build-wxmsw.bat", build fails. > This patch fixes this. > 0001-fix-cannot-build-wxWidgets-if-sources-are-located-at.patch Description: Binary data -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] Source reindenting
I just did a testrun with astyle to reindent and restyle the code. I created a rule in Makefile.am per: diff --git a/Makefile.am b/Makefile.am index be6af45..8266f8d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -65,3 +65,13 @@ endif # We need to ensure the help cache is world writeable install-data-hook: chmod 0666 $(help_cache) + +# Perform astyle cleanup per rules: +# * -p - insert space around parenthesis +# * -b - bracket style +# * -S - indent switches +# * -s4 - intent with spaces, 4 of them +# * -k3 - align pointer or reference operators +# Also add the -n to make it not save .orig files (we have git for that) +style: + astyle -n -p -b -S -s4 -k3 `find . -name "*.cpp" -o -name "*.h" | egrep -v "(wx-build|xrcDialogs|pgscript/test)"` diffstat for the whole thing is: 631 files changed, 36590 insertions(+), 30757 deletions(-) And yes, it is smart enough not to edit things if I run it again - phew. I've pushed a branch to github for your reviewing pleasure: https://github.com/mhagander/pgadmin3/compare/master...reindent It's going to cause merge conflicts like hell. but it's going to do that whenever we run it. So should we just go ahead and run it? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Source reindenting
On Wed, Dec 29, 2010 at 5:30 PM, Magnus Hagander wrote: > I just did a testrun with astyle to reindent and restyle the code. I > created a rule in Makefile.am per: > > diff --git a/Makefile.am b/Makefile.am > index be6af45..8266f8d 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -65,3 +65,13 @@ endif > # We need to ensure the help cache is world writeable > install-data-hook: > chmod 0666 $(help_cache) > + > +# Perform astyle cleanup per rules: > +# * -p - insert space around parenthesis > +# * -b - bracket style > +# * -S - indent switches > +# * -s4 - intent with spaces, 4 of them Didn't we say we were going to move to tabs? > It's going to cause merge conflicts like hell. but it's going to do > that whenever we run it. So should we just go ahead and run it? Why not? :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Source reindenting
On Wed, Dec 29, 2010 at 18:44, Dave Page wrote: > On Wed, Dec 29, 2010 at 5:30 PM, Magnus Hagander wrote: >> I just did a testrun with astyle to reindent and restyle the code. I >> created a rule in Makefile.am per: >> >> diff --git a/Makefile.am b/Makefile.am >> index be6af45..8266f8d 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -65,3 +65,13 @@ endif >> # We need to ensure the help cache is world writeable >> install-data-hook: >> chmod 0666 $(help_cache) >> + >> +# Perform astyle cleanup per rules: >> +# * -p - insert space around parenthesis >> +# * -b - bracket style >> +# * -S - indent switches >> +# * -s4 - intent with spaces, 4 of them > > Didn't we say we were going to move to tabs? I went by Guillaume's statement, which was that spaces was the last we said but there was some discussion about tabs that didn't really go anyway. I'm all for tabs on the basis that pg uses it. However, the diff is a lot bigger: 631 files changed, 87029 insertions(+), 81196 deletions(-) which indicates that we are using spaces a lot more today. >> It's going to cause merge conflicts like hell. but it's going to do >> that whenever we run it. So should we just go ahead and run it? > > Why not? :-) Because we haven't decided on tabs vs spaces yet? ;) Anyway, when that's done... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Source reindenting
On Wed, Dec 29, 2010 at 6:16 PM, Magnus Hagander wrote: > On Wed, Dec 29, 2010 at 18:44, Dave Page wrote: >> On Wed, Dec 29, 2010 at 5:30 PM, Magnus Hagander wrote: >>> I just did a testrun with astyle to reindent and restyle the code. I >>> created a rule in Makefile.am per: >>> >>> diff --git a/Makefile.am b/Makefile.am >>> index be6af45..8266f8d 100644 >>> --- a/Makefile.am >>> +++ b/Makefile.am >>> @@ -65,3 +65,13 @@ endif >>> # We need to ensure the help cache is world writeable >>> install-data-hook: >>> chmod 0666 $(help_cache) >>> + >>> +# Perform astyle cleanup per rules: >>> +# * -p - insert space around parenthesis >>> +# * -b - bracket style >>> +# * -S - indent switches >>> +# * -s4 - intent with spaces, 4 of them >> >> Didn't we say we were going to move to tabs? > > I went by Guillaume's statement, which was that spaces was the last we > said but there was some discussion about tabs that didn't really go > anyway. > > I'm all for tabs on the basis that pg uses it. However, the diff is a > lot bigger: > 631 files changed, 87029 insertions(+), 81196 deletions(-) > > which indicates that we are using spaces a lot more today. > > >>> It's going to cause merge conflicts like hell. but it's going to do >>> that whenever we run it. So should we just go ahead and run it? >> >> Why not? :-) > > Because we haven't decided on tabs vs spaces yet? ;) Anyway, when that's > done... Well, yeah. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Email notification pgAgent
Hi, I've made the necessary changes to pgAdmin, but how do we handle schema version conflicts? pgAdmin's job UI now will not work with pgAgent schema version 3, because of the changes in pgagent.pga_job table. I think we have two possibilities: 1. Disable editing Jobs in pgAdmin until a schema upgrade is done 2. Check schema version during GetUpdateSql and GetInsertSql and return two different versions of the statement. What do you think? I've got another two topics to discuss about pgAgent: 1. Step ordering I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, so we don't have to rename the steps "A_", "B_" if an ordering is required. In the GUI we would add an integer field to the "Change Step" mask. 2. Definition from File Add an extra job step type "SQL from file". The definition field would be treated as a path to a file, which contains SQL-Statements. Please let me know what you (all of you) think about the suggested features. Regards, Jasmin 2010/12/29 Dave Page > Hi > > On Tue, Dec 28, 2010 at 1:54 AM, Jasmin Dizdarevic > wrote: > > Okay, I'm almost done. Actually there is a problem with building the > wxSMTP > > package, so it doesn't send mails yet. > > If this is done, I'm going to test it on Windows and *nix. > > Ok. > > > Time to take care about some other things: > > 1. I'm coding on Windows with VS 2010. I've downloaded the source files > and > > run cmake to get a VS-Project. Here i made the changes. How I can > generate a > > patch file with git now, because I'm not working on the original source > > files - because of the cmake step? Have I to redo the changes on *nix? > > You need to update the CMakeLists.txt file from which the VC++ project > file and *nix build files are generated. > > > 2. What steps are necessary to send the changes to the community? Is > there a > > Just send a patch (git diff) to pgadmin-hack...@postgresql.org. > > > desired process and what's about the necessary changes in the pgAdmin UI? > > Will they be done by the maintainer of pgAdmin? Of course I'm ready to > > participate in pgAdmin too, but my knowledge of C++ and wx are limited, > so I > > can not promise best quality ;) > > The maintainers of pgAdmin are the same people, and no, they won't > automatically update the UI for the new feature I'm afraid (they have > enough work to do just keeping up with changes in PostgreSQL). Please > give it a try yourself, and we can help you iron out any kinks or > issues you may run into. > > Regards, Dave > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [pgadmin-hackers] Email notification pgAgent
Hi On Wed, Dec 29, 2010 at 6:55 PM, Jasmin Dizdarevic wrote: > Hi, > I've made the necessary changes to pgAdmin, but how do we handle schema > version conflicts? > pgAdmin's job UI now will not work with pgAgent schema version 3, because of > the changes in pgagent.pga_job table. I think we have two possibilities: > 1. Disable editing Jobs in pgAdmin until a schema upgrade is done > 2. Check schema version during GetUpdateSql and GetInsertSql and return two > different versions of the statement. > What do you think? I think 2. If the schema isn't of a high enough version, then the appropriate controls on the UI should also be disabled. This is akin to how we handle missing features in older versions of PostgreSQL itself. > I've got another two topics to discuss about pgAgent: > 1. Step ordering > I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, so > we don't have to rename the steps "A_", "B_" if an ordering is required. In > the GUI we would add an integer field to the "Change Step" mask. I'm not so keen on that - it could require some funky code to ensure that the user uses sequential (or at least, non-duplicate) numbers across all steps and would be a pain to upgrade to. Plus, there is precedence for using alpha ordering - that's how triggers work > 2. Definition from File > Add an extra job step type "SQL from file". The definition field would > be treated as a path to a file, which contains SQL-Statements. That seems like a potentially useful feature. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Keywords files
On Wed, Dec 29, 2010 at 4:40 PM, Magnus Hagander wrote: > On Wed, Dec 29, 2010 at 14:55, Dave Page wrote: >> On Wed, Dec 29, 2010 at 11:54 AM, Magnus Hagander >> wrote: >>> We haven't updated the keywords.cpp file for ages. In fact, so long >>> ago that the instructions are incorrect. >>> >>> Recent versions of postgresql installs the list of keywords in >>> kwlist.h. That requires PostgreSQL 8.4 or later. >>> >>> How old versions of the PostgreSQL *source* do we accept building >>> against? Couldn't we just switch to using this include file instead, >>> thus saying you need 8.4 or later to build? (it should still *run* >>> against earlier versions just fine..) >> >> Iirc, we need 8.3 (or whichever version included pgconninfoparse). I'm >> fine with moving to using the new include file - iirc, most distros >> have an 8.4 build now. > > That turned out to be a bit more work than I thought, mainly because > there were EnterpriseDB and Greenplum keywords included in the pgadmin > list - which was only documented in one of the two places where they > occurred :-) > > Anyway, attached is a patch that I believe does this right. If you > prefer an easier view, see > https://github.com/mhagander/pgadmin3/compare/master...keywords > > Does this look ok? > > It does move the keyword definitions out of the header and into > keywords.cpp - but they aren't used anywhere.. So in general, I'm > fairly confident with it... I don't see any obvious problems. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Fwd: [pgadmin-hackers] Email notification pgAgent
-- Forwarded message -- From: Jasmin Dizdarevic Date: 2010/12/29 Subject: Re: [pgadmin-hackers] Email notification pgAgent To: Dave Page Hi, * * *I'm not so keen on that - it could require some funky code to ensure* *that the user uses sequential (or at least, non-duplicate) numbers across all steps and would be a pain to upgrade to. Plus, there is precedence for using alpha ordering - that's how triggers work* I don't think that we must ensure that no duplicate values are used. With changing the "order by jstname,jstid" clause to "order by jstorder,jstname,jstid" we would have a fall back on alpha ordering. Steps with "jstorder" = null would be executed last - so there is no need to upgrade. To give the user feedback about ordering in pgadmin, the steps could be ordered the same way in tree view and steps tab in job properties dialog. We could also add the jstorder-column to the list view. 2010/12/29 Dave Page > Hi > > > On Wed, Dec 29, 2010 at 6:55 PM, Jasmin Dizdarevic > wrote: > > Hi, > > I've made the necessary changes to pgAdmin, but how do we handle schema > > version conflicts? > > pgAdmin's job UI now will not work with pgAgent schema version 3, because > of > > the changes in pgagent.pga_job table. I think we have two possibilities: > > 1. Disable editing Jobs in pgAdmin until a schema upgrade is done > > 2. Check schema version during GetUpdateSql and GetInsertSql and return > two > > different versions of the statement. > > What do you think? > > I think 2. If the schema isn't of a high enough version, then the > appropriate controls on the UI should also be disabled. This is akin > to how we handle missing features in older versions of PostgreSQL > itself. > > > I've got another two topics to discuss about pgAgent: > > 1. Step ordering > > I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, > so > > we don't have to rename the steps "A_", "B_" if an ordering is required. > In > > the GUI we would add an integer field to the "Change Step" mask. > > I'm not so keen on that - it could require some funky code to ensure > that the user uses sequential (or at least, non-duplicate) numbers > across all steps and would be a pain to upgrade to. Plus, there is > precedence for using alpha ordering - that's how triggers work > > > 2. Definition from File > > Add an extra job step type "SQL from file". The definition field > would > > be treated as a path to a file, which contains SQL-Statements. > > That seems like a potentially useful feature. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
[pgadmin-hackers] pgAdmin III commit: Fix the build-wxmsw.bat script to work in the case
Fix the build-wxmsw.bat script to work in the case that it is on a different drive than wxWidgets. Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=d5989136fe2a1ea9eb3ad80944cf1f45d6a4301a Author: Nail Samatov Modified Files -- xtra/wx-build/build-wxmsw.bat |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] fix: cannot build wxWidgets if sources are located at another disk
Thanks - patch committed. On Wed, Dec 29, 2010 at 4:47 PM, Nail Samatov wrote: > Sorry, forgot to attach the patch :-) > > 2010/12/29 Nail Samatov : >> For example, configuration wxWidgets sources are here: >> C:\libs\wxWidgets-2.8.11 >> PgAdmin sources are here: >> T:\my\pgadmin3 >> >> when in console I go to the "T:\my\pgadmin3\xtra\wx-build\" directory >> and run "build-wxmsw.bat", build fails. >> This patch fixes this. >> > > > -- > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-hackers > > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Source reindenting
Le 29/12/2010 18:44, Dave Page a écrit : > On Wed, Dec 29, 2010 at 5:30 PM, Magnus Hagander wrote: >> I just did a testrun with astyle to reindent and restyle the code. I >> created a rule in Makefile.am per: >> >> diff --git a/Makefile.am b/Makefile.am >> index be6af45..8266f8d 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -65,3 +65,13 @@ endif >> # We need to ensure the help cache is world writeable >> install-data-hook: >>chmod 0666 $(help_cache) >> + >> +# Perform astyle cleanup per rules: >> +# * -p - insert space around parenthesis >> +# * -b - bracket style >> +# * -S - indent switches >> +# * -s4 - intent with spaces, 4 of them > > Didn't we say we were going to move to tabs? > Yes. Magnus probably forgot that part when I talked with him on IM this morning (well, yesterday morning now). >> It's going to cause merge conflicts like hell. but it's going to do >> that whenever we run it. So should we just go ahead and run it? > > Why not? :-) > The only patches not yet commited that I know of are the GSoC projects. I know it won't be an issue for the database designer. Could be one for your project. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
