Re: [pgadmin-hackers] Re: [pgAdmin4][Patch][Feature #1971]: Remember column sizes between executions of the same query in the query tool
Hi As the patch "Improvements to Query Results" is merged, the columns width in edit grid needs some adjustments as 'checkboxes' are removed from columns. PFA patch. On Thu, Jun 8, 2017 at 5:12 PM, Dave Page wrote: > Nice! Thanks, patch applied. > > On Wed, Jun 7, 2017 at 4:03 PM, Surinder Kumar > wrote: > > PFA patch after rebase > > > > On Wed, Jun 7, 2017 at 6:26 PM, Surinder Kumar > > wrote: > >> > >> Hi > >> > >> Please find rebased patch. > >> > >> On Wed, Jun 7, 2017 at 6:15 PM, Dave Page wrote: > >>> > >>> Hi, > >>> > >>> Could you rebase this please? > >>> > >>> Thanks. > >>> > >>> On Tue, Jun 6, 2017 at 9:22 AM, Surinder Kumar > >>> wrote: > >>> > Hi All, > >>> > > >>> > Please find updated patch which includes Jasmine test cases for > >>> > functions > >>> > getHash and calculateColumnWidth > >>> > > >>> > Thanks, > >>> > Surinder > >>> > > >>> > On Mon, Jun 5, 2017 at 11:38 PM, Shruti B Iyer > >>> > wrote: > >>> >> > >>> >> Hi Surinder! > >>> >> > >>> >> We reviewed this patch. The changes look good and we especially like > >>> >> that > >>> >> you have extracted out the new utility functions and the > >>> >> epicRandomString > >>> >> function too. > >>> >> > >>> >> This patch will likely affect the Query Results patch that is > >>> >> currently > >>> >> under review. In order to assist either us or yourself when making a > >>> >> merge > >>> >> between these patches, it would help to have jasmine unit testing > for > >>> >> the > >>> >> two new functions, getHash and calculate_column_width. > >>> >> > >>> >> Also, we suggest that you rename calculate_column_width to > >>> >> calculateColumnWidth for consistency with javascript code style. > >>> >> > >>> >> Thanks, > >>> >> Shruti and Matt > >>> >> > >>> >> On Mon, Jun 5, 2017 at 9:16 AM Surinder Kumar > >>> >> wrote: > >>> >>> > >>> >>> Staged changes are missed in previous patch, so please ignore. > >>> >>> Please find attached updated patch. > >>> >>> > >>> >>> On Mon, Jun 5, 2017 at 4:29 PM, Surinder Kumar > >>> >>> wrote: > >>> > >>> Hi > >>> > >>> This patch contains two fixes: > >>> > >>> 1) In Query/tool or Edit grid, the width of table column header is > >>> fixed > >>> depending on the column type(int, boolean, char etc.) due to which > >>> the > >>> column name or type appears cut from right and doesn't looks good > >>> from user > >>> point of view. The main concern was to display as much as the > >>> content of > >>> column should be displayed. > >>> > >>> Now the width of column is decided using the text length of column > >>> name > >>> or column type so that the column takes exact width it required > and > >>> it don't > >>> appears cut. > >>> > >>> 2) Remember column size after re-running a query. > >>> > >>> The approach is to extract table name from the query executed and > >>> use it > >>> to store its columns width. > >>> Whenever the column(s) width of a table is adjusted, the > >>> corresponding > >>> values are updated into the object and used every time the same > >>> query is > >>> executed. > >>> > >>> If a query is executed for e.g: > >>> > >>> SELECT generate_series(1, 1000) as id, generate_series(1, 1000) as > >>> name, > >>> generate_series(1, 1000) as age > >>> > >>> it > >>> displays 3 columns > >>> but don't have any table name. In that case, > >>> i use a hash generator function which returns unique hash for a > >>> query > >>> written in query editor and adjusted column(s) width are stored > >>> against that > >>> hash in object. > >>> > >>> Is there any way to get temporary table name(avoiding unique hash) > >>> for > >>> such queries ? > >>> > >>> Also, Moved utilities functions into pgadmin/static/utils.js > >>> > >>> Please find attached patch and review. > >>> > >>> Thanks, > >>> Surinder Kumar > >>> >>> > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> Sent via pgadmin-hackers mailing list > >>> >>> (pgadmin-hackers@postgresql.org) > >>> >>> To make changes to your subscription: > >>> >>> http://www.postgresql.org/mailpref/pgadmin-hackers > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Sent via pgadmin-hackers mailing list (pgadmin-hack...@postgresql.or > g) > >>> > 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 > >> > >> > > > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > adjust_columns_width.patch Description: Binary data -- Sent vi
Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query Results Grid User Experience
On Thu, Jun 8, 2017 at 7:31 PM, Sarah McAlear wrote: >> Thanks. When I run the tests my browser opens in some default size >> that's always consistent, but doesn't match my normal Chrome sessions, >> or the 1024x1024 default set in app_starter.py. > > > This looks like an issue with string edit box placement in the > implementation. We created an issue for this (RM2477). That was my guess too. >> Anyway - I found another issue. If I select one or more columns or >> rows, or an arbitrary selection of cells, copy/paste seems to work >> fine. However, if I click the Select All arrow, for a small resultset >> (e.g. SELECT * FROM pg_database with 18 rows) it works fine, but if I >> do the same with the contents of pg_class, which has 1342 rows on this >> DB, it seems to fail to populate the clipboard and ends up pasting >> whatever was copied previously instead. If I use the Copy button, even >> on a fast machine it seems to pause for a second or so before failing >> to put the data on the clipboard. > > > We were able to reproduce this with "SELECT generate_series(1, 5)" > The issue was still present for us when we ran the app at each of 2fddf750 > and 495a3cedb > Could we move this discussion to a new thread as it doesn't seem related to > these changes? Something in these changes caused it to start manifesting, but I agree the underlying issue was probably there anyway. I'm happy to move to a different thread. -- 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] pgAdmin 4 commit: Use the correct font for the treeview.
Use the correct font for the treeview. Branch -- master Details --- https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=ee4a84778457e3ca022be4e2c7f730c98a5e3422 Author: Sarah McAlear Modified Files -- web/pgadmin/static/css/aci_tree.overrides.css | 4 web/pgadmin/templates/base.html | 1 + 2 files changed, 5 insertions(+) -- 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][patch] Changing the ACI tree font to Helvetica
Thanks - I'm not 100% sure it's as easy to read as it was. Oddly, I wonder if the size needs reducing a little (to increase the whitespace around each label), but I think we need more eyes on it to decide if I'm just imagining that so I've committed it for now, and we can tweak later if needed. On Thu, Jun 8, 2017 at 10:54 PM, Sarah McAlear wrote: > Hi Hackers, > > This patch changes the ACI Tree font to the font used in the rest of the > project and increases the size to match, Helvetica. > > Thanks, > Shirley & Sarah > > > > > -- > 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] [pgAdmin4][Patch][Feature_1535]: Pressing ESC from within a dialog box should act like "Cancel" button
Hi Ahh, now we have a bug. In the properties dialogues, if you edit a comment, as soon as the Save button gets enabled, hitting Return will Save the changes instead of adding a newline to the comment. That's clearly not right :-( On Fri, Jun 9, 2017 at 7:48 AM, Surinder Kumar wrote: > Hi > > Please find updated patch. > > Thanks, > Surinder > > On Thu, Jun 8, 2017 at 7:16 PM, Dave Page wrote: >> >> Hi >> >> On Thu, Jun 8, 2017 at 5:38 AM, Surinder Kumar >> wrote: >> > Hi >> > >> > The attribute key for Ok, Save buttons should be mapped to 13(Enter), >> > for Help - 112(F1) and >> > for Cancel - 27(Esc) >> > The above changes are made into all dialog related template files. >> > >> > PFA patch and review. >> >> Looks good. Just a couple of thoughts: >> >> - You've missed the object property dialogues. This really needs to be >> consistent across all dialogues :-) >> >> - The behaviour with Enter is a bit odd, because priority will be >> given the the focussed control to handle it. That's what we want if >> it's a text area for example, but on the other hand, if you open the >> Preference dialogue, then the Help button gets focus first, so Enter >> there will end up opening the docs. I suspect in most cases the >> behaviour you've got is fine, so I'm not inclined to change it. > a little> Hmm, I see similar behaviour in some other apps. Let's leave >> it as you've done it :-) >> >> Please add support for the properties dialogues, then I think we're good >> to go. > > Done. >> >> >> Thanks! >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company > > -- 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] pgAdmin 4 commit: Fine tune result grid column sizing now we don't have
Fine tune result grid column sizing now we don't have checkboxes. Branch -- master Details --- https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=49976b193476c7626c305853c23cbf9a98af68e8 Author: Surinder Kumar Modified Files -- web/pgadmin/static/js/sqleditor_utils.js | 2 +- .../tools/sqleditor/templates/sqleditor/js/sqleditor.js| 10 +- 2 files changed, 6 insertions(+), 6 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] Re: [pgAdmin4][Patch][Feature #1971]: Remember column sizes between executions of the same query in the query tool
Thanks, applied. On Fri, Jun 9, 2017 at 8:39 AM, Surinder Kumar wrote: > Hi > > As the patch "Improvements to Query Results" > is merged, the columns width in edit grid needs some adjustments as > 'checkboxes' are removed from columns. > > PFA patch. > > On Thu, Jun 8, 2017 at 5:12 PM, Dave Page wrote: >> >> Nice! Thanks, patch applied. >> >> On Wed, Jun 7, 2017 at 4:03 PM, Surinder Kumar >> wrote: >> > PFA patch after rebase >> > >> > On Wed, Jun 7, 2017 at 6:26 PM, Surinder Kumar >> > wrote: >> >> >> >> Hi >> >> >> >> Please find rebased patch. >> >> >> >> On Wed, Jun 7, 2017 at 6:15 PM, Dave Page wrote: >> >>> >> >>> Hi, >> >>> >> >>> Could you rebase this please? >> >>> >> >>> Thanks. >> >>> >> >>> On Tue, Jun 6, 2017 at 9:22 AM, Surinder Kumar >> >>> wrote: >> >>> > Hi All, >> >>> > >> >>> > Please find updated patch which includes Jasmine test cases for >> >>> > functions >> >>> > getHash and calculateColumnWidth >> >>> > >> >>> > Thanks, >> >>> > Surinder >> >>> > >> >>> > On Mon, Jun 5, 2017 at 11:38 PM, Shruti B Iyer >> >>> > wrote: >> >>> >> >> >>> >> Hi Surinder! >> >>> >> >> >>> >> We reviewed this patch. The changes look good and we especially >> >>> >> like >> >>> >> that >> >>> >> you have extracted out the new utility functions and the >> >>> >> epicRandomString >> >>> >> function too. >> >>> >> >> >>> >> This patch will likely affect the Query Results patch that is >> >>> >> currently >> >>> >> under review. In order to assist either us or yourself when making >> >>> >> a >> >>> >> merge >> >>> >> between these patches, it would help to have jasmine unit testing >> >>> >> for >> >>> >> the >> >>> >> two new functions, getHash and calculate_column_width. >> >>> >> >> >>> >> Also, we suggest that you rename calculate_column_width to >> >>> >> calculateColumnWidth for consistency with javascript code style. >> >>> >> >> >>> >> Thanks, >> >>> >> Shruti and Matt >> >>> >> >> >>> >> On Mon, Jun 5, 2017 at 9:16 AM Surinder Kumar >> >>> >> wrote: >> >>> >>> >> >>> >>> Staged changes are missed in previous patch, so please ignore. >> >>> >>> Please find attached updated patch. >> >>> >>> >> >>> >>> On Mon, Jun 5, 2017 at 4:29 PM, Surinder Kumar >> >>> >>> wrote: >> >>> >> >>> Hi >> >>> >> >>> This patch contains two fixes: >> >>> >> >>> 1) In Query/tool or Edit grid, the width of table column header >> >>> is >> >>> fixed >> >>> depending on the column type(int, boolean, char etc.) due to >> >>> which >> >>> the >> >>> column name or type appears cut from right and doesn't looks good >> >>> from user >> >>> point of view. The main concern was to display as much as the >> >>> content of >> >>> column should be displayed. >> >>> >> >>> Now the width of column is decided using the text length of >> >>> column >> >>> name >> >>> or column type so that the column takes exact width it required >> >>> and >> >>> it don't >> >>> appears cut. >> >>> >> >>> 2) Remember column size after re-running a query. >> >>> >> >>> The approach is to extract table name from the query executed and >> >>> use it >> >>> to store its columns width. >> >>> Whenever the column(s) width of a table is adjusted, the >> >>> corresponding >> >>> values are updated into the object and used every time the same >> >>> query is >> >>> executed. >> >>> >> >>> If a query is executed for e.g: >> >>> >> >>> SELECT generate_series(1, 1000) as id, generate_series(1, 1000) >> >>> as >> >>> name, >> >>> generate_series(1, 1000) as age >> >>> >> >>> it >> >>> displays 3 columns >> >>> but don't have any table name. In that case, >> >>> i use a hash generator function which returns unique hash for a >> >>> query >> >>> written in query editor and adjusted column(s) width are stored >> >>> against that >> >>> hash in object. >> >>> >> >>> Is there any way to get temporary table name(avoiding unique >> >>> hash) >> >>> for >> >>> such queries ? >> >>> >> >>> Also, Moved utilities functions into pgadmin/static/utils.js >> >>> >> >>> Please find attached patch and review. >> >>> >> >>> Thanks, >> >>> Surinder Kumar >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> -- >> >>> >>> Sent via pgadmin-hackers mailing list >> >>> >>> (pgadmin-hackers@postgresql.org) >> >>> >>> To make changes to your subscription: >> >>> >>> http://www.postgresql.org/mailpref/pgadmin-hackers >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > 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 >> >>>
Re: [pgadmin-hackers] [pgAdmin4][Patch][Feature_1535]: Pressing ESC from within a dialog box should act like "Cancel" button
Hi PFA patch and review. On Fri, Jun 9, 2017 at 1:47 PM, Dave Page wrote: > Hi > > Ahh, now we have a bug. In the properties dialogues, if you edit a > comment, as soon as the Save button gets enabled, hitting Return will > Save the changes instead of adding a newline to the comment. That's > clearly not right :-( > Now if event.target is its child elements(for example input, textarea etc), the function "handleKeyDown(event)" won't call. > > On Fri, Jun 9, 2017 at 7:48 AM, Surinder Kumar > wrote: > > Hi > > > > Please find updated patch. > > > > Thanks, > > Surinder > > > > On Thu, Jun 8, 2017 at 7:16 PM, Dave Page wrote: > >> > >> Hi > >> > >> On Thu, Jun 8, 2017 at 5:38 AM, Surinder Kumar > >> wrote: > >> > Hi > >> > > >> > The attribute key for Ok, Save buttons should be mapped to 13(Enter), > >> > for Help - 112(F1) and > >> > for Cancel - 27(Esc) > >> > The above changes are made into all dialog related template files. > >> > > >> > PFA patch and review. > >> > >> Looks good. Just a couple of thoughts: > >> > >> - You've missed the object property dialogues. This really needs to be > >> consistent across all dialogues :-) > >> > >> - The behaviour with Enter is a bit odd, because priority will be > >> given the the focussed control to handle it. That's what we want if > >> it's a text area for example, but on the other hand, if you open the > >> Preference dialogue, then the Help button gets focus first, so Enter > >> there will end up opening the docs. I suspect in most cases the > >> behaviour you've got is fine, so I'm not inclined to change it. >> a little> Hmm, I see similar behaviour in some other apps. Let's leave > >> it as you've done it :-) > >> > >> Please add support for the properties dialogues, then I think we're good > >> to go. > > > > Done. > >> > >> > >> Thanks! > >> > >> -- > >> Dave Page > >> Blog: http://pgsnake.blogspot.com > >> Twitter: @pgsnake > >> > >> EnterpriseDB UK: http://www.enterprisedb.com > >> The Enterprise PostgreSQL Company > > > > > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > Feature_1533_v2.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
Re: [pgadmin-hackers] [pgAdmin4][Patch][Feature_1535]: Pressing ESC from within a dialog box should act like "Cancel" button
Ignore previous patch as it doesn't contains new changes. Please find attached patch. On Fri, Jun 9, 2017 at 3:06 PM, Surinder Kumar wrote: > Hi > > PFA patch and review. > > > On Fri, Jun 9, 2017 at 1:47 PM, Dave Page wrote: > >> Hi >> >> Ahh, now we have a bug. In the properties dialogues, if you edit a >> comment, as soon as the Save button gets enabled, hitting Return will >> Save the changes instead of adding a newline to the comment. That's >> clearly not right :-( >> > Now if event.target is its child elements(for example input, textarea > etc), the function "handleKeyDown(event)" won't call. > >> >> On Fri, Jun 9, 2017 at 7:48 AM, Surinder Kumar >> wrote: >> > Hi >> > >> > Please find updated patch. >> > >> > Thanks, >> > Surinder >> > >> > On Thu, Jun 8, 2017 at 7:16 PM, Dave Page wrote: >> >> >> >> Hi >> >> >> >> On Thu, Jun 8, 2017 at 5:38 AM, Surinder Kumar >> >> wrote: >> >> > Hi >> >> > >> >> > The attribute key for Ok, Save buttons should be mapped to 13(Enter), >> >> > for Help - 112(F1) and >> >> > for Cancel - 27(Esc) >> >> > The above changes are made into all dialog related template files. >> >> > >> >> > PFA patch and review. >> >> >> >> Looks good. Just a couple of thoughts: >> >> >> >> - You've missed the object property dialogues. This really needs to be >> >> consistent across all dialogues :-) >> >> >> >> - The behaviour with Enter is a bit odd, because priority will be >> >> given the the focussed control to handle it. That's what we want if >> >> it's a text area for example, but on the other hand, if you open the >> >> Preference dialogue, then the Help button gets focus first, so Enter >> >> there will end up opening the docs. I suspect in most cases the >> >> behaviour you've got is fine, so I'm not inclined to change it. > >> a little> Hmm, I see similar behaviour in some other apps. Let's leave >> >> it as you've done it :-) >> >> >> >> Please add support for the properties dialogues, then I think we're >> good >> >> to go. >> > >> > Done. >> >> >> >> >> >> Thanks! >> >> >> >> -- >> >> Dave Page >> >> Blog: http://pgsnake.blogspot.com >> >> Twitter: @pgsnake >> >> >> >> EnterpriseDB UK: http://www.enterprisedb.com >> >> The Enterprise PostgreSQL Company >> > >> > >> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > Feature_1533_v2.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
Re: [pgadmin-hackers] [pgAdmin4][Patch][RM_2450] : Internal Server Error displayed if click on statistic tab for PG 10 server
Hi Dave, I have made the template search code to work for 10_plus directory name. Please review the attached patch Regards, Atul. On Thu, Jun 8, 2017 at 7:55 PM, Dave Page wrote: > Hi Atul, > > On Thu, Jun 8, 2017 at 3:03 PM, Atul Sharma > wrote: > > Hi, > > > > The issue is fixed now. Added a new "stats.sql" file with updated columns > > for the version 10.0_plus > > > > PFA RM patch. > > As PostgreSQL has moved to a 2 digit version number system instead of > 3, I think the directory name should be 10_plus shouldn't it? Will > that work with the template search code? If not, can you please fix > that as well? > > Thanks! > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > RM_2450_ver1.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
Re: [pgadmin-hackers][patch] Changing the ACI tree font to Helvetica
I'm with you on that. I had to use the browser with Helvetica for about day before I could make a comparison with using Verdana. On Fri, Jun 9, 2017 at 4:11 AM Dave Page wrote: > Thanks - I'm not 100% sure it's as easy to read as it was. Oddly, I > wonder if the size needs reducing a little (to increase the whitespace > around each label), but I think we need more eyes on it to decide if > I'm just imagining that so I've committed it for now, and we can tweak > later if needed. > > On Thu, Jun 8, 2017 at 10:54 PM, Sarah McAlear > wrote: > > Hi Hackers, > > > > This patch changes the ACI Tree font to the font used in the rest of the > > project and increases the size to match, Helvetica. > > > > Thanks, > > Shirley & Sarah > > > > > > > > > > -- > > 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 >
