Re: [pgadmin-support] Broken pgadmin.org website link
On Tue, Jan 18, 2011 at 7:24 PM, Otto Hirr wrote: > FYI, > > The link for > > Page http://www.pgadmin.org/download/windows.php states: > > Note that the pgInstaller distribution of PostgreSQL > for Windows includes a bundled copy of pgAdmin. > > where 'pgInstaller' is a link to a non-existent directory. > > > Possibly it should be changed to the link on page > http://www.postgresql.org/download/windows > which points to > http://www.enterprisedb.com/products/pgdownload.do#windows I've changed it to point directly at the latest download page URL. The change will show up soon. > The page, http://www.postgresql.org/download/windows, could > use a bit more work on disambiguating the differences between > "One Click Installer" and "pgInstaller"... (but then that is > a different site, however since this will most likely go to > Dave Page, who most likely can update both, I thought I'd > make a comment...) That page was written after a great deal of discussion and a lot of bikeshedding to figure out the best content - I don't want to re-open that discussion whilst the majority of people are happy with it! Plus, I disagree. It tells you the focus of each package, it tells you who maintains them (both the company - where applicable - and the people), and it warns that pgInstaller is only maintained for 8.2/8.3. Thanks for the feedback though :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
[pgadmin-support] logging problem on OS X
Does anyone know where the directory path for logging files comes from, under "Options -> Logging"? I have a newly downloaded binary of pgadmin (1.12), that defaults to an old user that does not exist on my machine. Any attempt to reset the path with the browse command causes pgadmin to crash/quit. I am getting the "can't write logfile" message when I try and connect to my server. However, I have already set the listen address parameter to "*", and added 0.0.0.0/24 md5 to pg_hba.conf file. When I noticed the directory path issue, I wondered if that could be part of the problem. The user name is an old user that does not exist on the system anymore. There must be a file somewhere that was not deleted when I tossed the old version of pgadmin. I am running OS X 10.6.x postgresql 9.x and have tried pgadmin 1.12.2 and 1.12.1 Any suggestions would be much appreciated. -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] logging problem on OS X
On Wed, Jan 19, 2011 at 2:52 PM, Kirk Wythers wrote: > Does anyone know where the directory path for logging files comes from, under > "Options -> Logging"? I have a newly downloaded binary of pgadmin (1.12), > that defaults to an old user that does not exist on my machine. Any attempt > to reset the path with the browse command causes pgadmin to crash/quit. > > I am getting the "can't write logfile" message when I try and connect to my > server. However, I have already set the listen address parameter to "*", and > added 0.0.0.0/24 md5 to pg_hba.conf file. When I noticed the directory path > issue, I wondered if that could be part of the problem. The user name is an > old user that does not exist on the system anymore. There must be a file > somewhere that was not deleted when I tossed the old version of pgadmin. > > I am running OS X 10.6.x postgresql 9.x and have tried pgadmin 1.12.2 and > 1.12.1 Sounds like something pretty funky is going on on your machine. Did you take ownership of any of the files owned by the ex-account holder? The settings are stored on a per-user basis, in "~/Library/Preferences/pgadmin3 Preferences". It's in ini file format, so you should be able to edit the value in there. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] pg_listener table errors with slony
Le 14/01/2011 00:27, Guillaume Lelarge a écrit : > Le 14/01/2011 00:09, Ben Carbery a écrit : >> [...] >> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >> Whenever I click on certain elements of the object browser associated with >> replication I get an error: >> >> ERROR: relation pg_listener does not exist >> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >> >> This occur under Replication-> for example or when clicking on >> nodes under that. This also occurs on 12.2.1. >> >> I believe this table no longer exists in 9.0 so I guess this is technically >> a bug. Should it be logged as such? >> > > Well, pgAdmin fires this query. As you say, this table no longer exists > since the rework on the listen/notify mechanism done for 9.0. So, yeah, > this is a bug in pgAdmin. > > I'll try to work on this tomorrow. > Got a look at this, and I reproduce the error. I don't think we have any support of Slony 2.0. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] pg_listener table errors with slony
On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge wrote: > Le 14/01/2011 00:27, Guillaume Lelarge a écrit : >> Le 14/01/2011 00:09, Ben Carbery a écrit : >>> [...] >>> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >>> Whenever I click on certain elements of the object browser associated with >>> replication I get an error: >>> >>> ERROR: relation pg_listener does not exist >>> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >>> >>> This occur under Replication-> for example or when clicking on >>> nodes under that. This also occurs on 12.2.1. >>> >>> I believe this table no longer exists in 9.0 so I guess this is technically >>> a bug. Should it be logged as such? >>> >> >> Well, pgAdmin fires this query. As you say, this table no longer exists >> since the rework on the listen/notify mechanism done for 9.0. So, yeah, >> this is a bug in pgAdmin. >> >> I'll try to work on this tomorrow. >> > > Got a look at this, and I reproduce the error. I don't think we have any > support of Slony 2.0. We did. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] pg_listener table errors with slony
Le 19/01/2011 22:23, Dave Page a écrit : > On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge > wrote: >> Le 14/01/2011 00:27, Guillaume Lelarge a écrit : >>> Le 14/01/2011 00:09, Ben Carbery a écrit : [...] I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. Whenever I click on certain elements of the object browser associated with replication I get an error: ERROR: relation pg_listener does not exist LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... This occur under Replication-> for example or when clicking on nodes under that. This also occurs on 12.2.1. I believe this table no longer exists in 9.0 so I guess this is technically a bug. Should it be logged as such? >>> >>> Well, pgAdmin fires this query. As you say, this table no longer exists >>> since the rework on the listen/notify mechanism done for 9.0. So, yeah, >>> this is a bug in pgAdmin. >>> >>> I'll try to work on this tomorrow. >>> >> >> Got a look at this, and I reproduce the error. I don't think we have any >> support of Slony 2.0. > > We did. > We had 1.2 support. To have 2.0, we would have to get rid of the sl_trigger checks. Or was it dropped along the way of 2.0? -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] pg_listener table errors with slony
On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge wrote: > Le 19/01/2011 22:23, Dave Page a écrit : >> On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge >> wrote: >>> Le 14/01/2011 00:27, Guillaume Lelarge a écrit : Le 14/01/2011 00:09, Ben Carbery a écrit : > [...] > I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. > Whenever I click on certain elements of the object browser associated with > replication I get an error: > > ERROR: relation pg_listener does not exist > LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... > > This occur under Replication-> for example or when clicking > on > nodes under that. This also occurs on 12.2.1. > > I believe this table no longer exists in 9.0 so I guess this is > technically > a bug. Should it be logged as such? > Well, pgAdmin fires this query. As you say, this table no longer exists since the rework on the listen/notify mechanism done for 9.0. So, yeah, this is a bug in pgAdmin. I'll try to work on this tomorrow. >>> >>> Got a look at this, and I reproduce the error. I don't think we have any >>> support of Slony 2.0. >> >> We did. >> > > We had 1.2 support. To have 2.0, we would have to get rid of the > sl_trigger checks. Or was it dropped along the way of 2.0? No idea - I just recall Sachin working on compatibility, and that was one of/the patch he came of with. FWIW, I'd be happy to drop support. I don't think many people use it, and it certainly doesn't get tested enough. Plus, it's just one of many replication engines. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] pg_listener table errors with slony
Le 19/01/2011 22:33, Dave Page a écrit : > On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge > wrote: >> Le 19/01/2011 22:23, Dave Page a écrit : >>> On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge >>> wrote: Le 14/01/2011 00:27, Guillaume Lelarge a écrit : > Le 14/01/2011 00:09, Ben Carbery a écrit : >> [...] >> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >> Whenever I click on certain elements of the object browser associated >> with >> replication I get an error: >> >> ERROR: relation pg_listener does not exist >> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >> >> This occur under Replication-> for example or when >> clicking on >> nodes under that. This also occurs on 12.2.1. >> >> I believe this table no longer exists in 9.0 so I guess this is >> technically >> a bug. Should it be logged as such? >> > > Well, pgAdmin fires this query. As you say, this table no longer exists > since the rework on the listen/notify mechanism done for 9.0. So, yeah, > this is a bug in pgAdmin. > > I'll try to work on this tomorrow. > Got a look at this, and I reproduce the error. I don't think we have any support of Slony 2.0. >>> >>> We did. >>> >> >> We had 1.2 support. To have 2.0, we would have to get rid of the >> sl_trigger checks. Or was it dropped along the way of 2.0? > > No idea - I just recall Sachin working on compatibility, and that was > one of/the patch he came of with. > Yeah, you're right. I now see the commit. Which means we have two bugs on 2.0 support. > FWIW, I'd be happy to drop support. I don't think many people use it, > and it certainly doesn't get tested enough. I kind of agree for it not being tested enough. > Plus, it's just one of many replication engines. > This isn't a good reason to me. I would like to see something alike for SR. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] pg_listener table errors with slony
On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge wrote: > Le 19/01/2011 22:33, Dave Page a écrit : > >> Plus, it's just one of many replication engines. >> > > This isn't a good reason to me. I would like to see something alike for SR. My point is, why should we support one external replication engine over another? Originally, it was because Slony was the only one worth considering, but that really isn't the case any more. I think SR is a different case - it's part of PostgreSQL, so certainly should be supported as makes sense. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] pg_listener table errors with slony
Le 19/01/2011 22:47, Dave Page a écrit : > On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge > wrote: >> Le 19/01/2011 22:33, Dave Page a écrit : >> >>> Plus, it's just one of many replication engines. >>> >> >> This isn't a good reason to me. I would like to see something alike for SR. > > My point is, why should we support one external replication engine > over another? Originally, it was because Slony was the only one worth > considering, but that really isn't the case any more. > I don't see it that way. We don't support one over another. As you say, we support Slony because at the time, it was the only one worth it. We don't support the other ones because we don't have time to work on this. It isn't a case of "Slony is better, X is crap". It's just that we lack time (and perhaps motivation too) to add support for another one. Actually, I would have no problem adding another one, like Londiste for example. I don't have time to code this myself, but if someone does, I have no problem to see his work commited. > I think SR is a different case - it's part of PostgreSQL, so certainly > should be supported as makes sense. > Yeah, that makes sense. But it doesn't mean we should get rid of something working (apart from those two bugs). -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] Minor UI issues for Server Properties dialog box
Le 16/01/2011 09:32, Dave Page a écrit : > On Sat, Jan 15, 2011 at 11:17 PM, Guillaume Lelarge > wrote: >> Le 15/01/2011 23:58, Josh Berkus a écrit : >>> Nothing showstopping, but: >>> >>> 1) After you make changes in the Server Properties dialog, it gives you >>> the fairly useless message that "Some changes will not take effect until >>> the next time pgAdmin connects to the server". The reason this message >>> is useless (and annoying) is that pgAdmin prevents you from changing >>> those fields unless you are disconnected from the server in the first place. >>> >> >> Yeah, I don't like it either. Need to be fixed. > > Actually, it is correct; you can tweak the DB Restriction, but it > needs a full refresh to take effect. That said, it is inconsistent > from other settings. > > I commited a patch that simply displays the message only when the user is connected to the server. Now, what I would like to know is if the other settings should stay disabled? why only some of them are disabled (or enabled)? shouldn't we just make them all enabled? -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] Minor UI issues for Server Properties dialog box
On Wed, Jan 19, 2011 at 10:38 PM, Guillaume Lelarge wrote: > Le 16/01/2011 09:32, Dave Page a écrit : >> On Sat, Jan 15, 2011 at 11:17 PM, Guillaume Lelarge >> wrote: >>> Le 15/01/2011 23:58, Josh Berkus a écrit : Nothing showstopping, but: 1) After you make changes in the Server Properties dialog, it gives you the fairly useless message that "Some changes will not take effect until the next time pgAdmin connects to the server". The reason this message is useless (and annoying) is that pgAdmin prevents you from changing those fields unless you are disconnected from the server in the first place. >>> >>> Yeah, I don't like it either. Need to be fixed. >> >> Actually, it is correct; you can tweak the DB Restriction, but it >> needs a full refresh to take effect. That said, it is inconsistent >> from other settings. >> >> > > I commited a patch that simply displays the message only when the user > is connected to the server. > > Now, what I would like to know is if the other settings should stay > disabled? why only some of them are disabled (or enabled)? shouldn't we > just make them all enabled? I'd be inclined to make them all disabled. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] Minor UI issues for Server Properties dialog box
Le 19/01/2011 23:42, Dave Page a écrit : > On Wed, Jan 19, 2011 at 10:38 PM, Guillaume Lelarge > wrote: >> Le 16/01/2011 09:32, Dave Page a écrit : >>> On Sat, Jan 15, 2011 at 11:17 PM, Guillaume Lelarge >>> wrote: Le 15/01/2011 23:58, Josh Berkus a écrit : > Nothing showstopping, but: > > 1) After you make changes in the Server Properties dialog, it gives you > the fairly useless message that "Some changes will not take effect until > the next time pgAdmin connects to the server". The reason this message > is useless (and annoying) is that pgAdmin prevents you from changing > those fields unless you are disconnected from the server in the first > place. > Yeah, I don't like it either. Need to be fixed. >>> >>> Actually, it is correct; you can tweak the DB Restriction, but it >>> needs a full refresh to take effect. That said, it is inconsistent >>> from other settings. >>> >>> >> >> I commited a patch that simply displays the message only when the user >> is connected to the server. >> >> Now, what I would like to know is if the other settings should stay >> disabled? why only some of them are disabled (or enabled)? shouldn't we >> just make them all enabled? > > I'd be inclined to make them all disabled. > When one is connected, right? (if not, we couldn't do much after creating it :) ). Which means we would get rid of the message, as a user won't be able to change server's settings once connected to it. Makes sense to me. Working on it. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] Minor UI issues for Server Properties dialog box
Le 19/01/2011 23:51, Guillaume Lelarge a écrit :
> Le 19/01/2011 23:42, Dave Page a écrit :
>> On Wed, Jan 19, 2011 at 10:38 PM, Guillaume Lelarge
>> wrote:
>>> Le 16/01/2011 09:32, Dave Page a écrit :
On Sat, Jan 15, 2011 at 11:17 PM, Guillaume Lelarge
wrote:
> Le 15/01/2011 23:58, Josh Berkus a écrit :
>> Nothing showstopping, but:
>>
>> 1) After you make changes in the Server Properties dialog, it gives you
>> the fairly useless message that "Some changes will not take effect until
>> the next time pgAdmin connects to the server". The reason this message
>> is useless (and annoying) is that pgAdmin prevents you from changing
>> those fields unless you are disconnected from the server in the first
>> place.
>>
>
> Yeah, I don't like it either. Need to be fixed.
Actually, it is correct; you can tweak the DB Restriction, but it
needs a full refresh to take effect. That said, it is inconsistent
from other settings.
>>>
>>> I commited a patch that simply displays the message only when the user
>>> is connected to the server.
>>>
>>> Now, what I would like to know is if the other settings should stay
>>> disabled? why only some of them are disabled (or enabled)? shouldn't we
>>> just make them all enabled?
>>
>> I'd be inclined to make them all disabled.
>>
>
> When one is connected, right? (if not, we couldn't do much after
> creating it :) ). Which means we would get rid of the message, as a user
> won't be able to change server's settings once connected to it. Makes
> sense to me. Working on it.
>
Got a patch, but I'm wondering if this is 1.12 material? or is it 1.14
only? actually, Josh's bug is fixed, so this could be 1.14 only. Any
opinions on this matter?
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
diff --git a/pgadmin/dlg/dlgServer.cpp b/pgadmin/dlg/dlgServer.cpp
index 1bd9d98..cbf58f2 100644
--- a/pgadmin/dlg/dlgServer.cpp
+++ b/pgadmin/dlg/dlgServer.cpp
@@ -144,6 +144,7 @@ void dlgServer::OnOK(wxCommandEvent &ev)
if (!btnOK->IsEnabled())
return;
#endif
+
// Display the 'save password' hint if required
if(chkStorePwd->GetValue())
{
@@ -152,10 +153,8 @@ void dlgServer::OnOK(wxCommandEvent &ev)
}
// notice: changes active after reconnect
-
EnableOK(false);
-
if (server)
{
server->iSetName(GetName());
@@ -257,9 +256,6 @@ void dlgServer::OnOK(wxCommandEvent &ev)
}
server->iSetGroup(cbGroup->GetValue());
-if (connection)
- wxMessageBox(_("Note: some changes to server settings may only take effect the next time pgAdmin connects to the server."), _("Server settings"), wxICON_INFORMATION);
-
mainForm->execSelChange(server->GetId(), true);
mainForm->GetBrowser()->SetItemText(item, server->GetFullName());
mainForm->SetItemBackgroundColour(item, wxColour(server->GetColour()));
@@ -364,12 +360,19 @@ int dlgServer::Go(bool modal)
txtPassword->Disable();
if (connection)
{
+ txtDescription->Disable();
+ txtService->Disable();
txtName->Disable();
cbDatabase->Disable();
txtPort->Disable();
cbSSL->Disable();
txtUsername->Disable();
chkStorePwd->Disable();
+ chkRestore->Disable();
+ txtDbRestriction->Disable();
+ colourPicker->Disable();
+ cbGroup->Disable();
+ EnableOK(false);
}
}
else
@@ -414,8 +417,8 @@ pgObject *dlgServer::CreateObject(pgCollection *collection)
void dlgServer::OnChangeTryConnect(wxCommandEvent &ev)
{
- chkStorePwd->Enable(chkTryConnect->GetValue());
- txtPassword->Enable(chkTryConnect->GetValue());
+ chkStorePwd->Enable(chkTryConnect->GetValue() && !connection);
+ txtPassword->Enable(chkTryConnect->GetValue() && !connection);
OnChange(ev);
}
@@ -451,7 +454,6 @@ void dlgServer::CheckChange()
|| cbGroup->GetValue() != server->GetGroup();
}
-
#ifdef __WXMSW__
CheckValid(enable, !name.IsEmpty(), _("Please specify address."));
#else
@@ -463,7 +465,7 @@ void dlgServer::CheckChange()
CheckValid(enable, !txtUsername->GetValue().IsEmpty(), _("Please specify user name"));
CheckValid(enable, dbRestrictionOk, _("Restriction not valid."));
- EnableOK(enable);
+ EnableOK(enable && !connection);
}
--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] Minor UI issues for Server Properties dialog box
On Wed, Jan 19, 2011 at 11:10 PM, Guillaume Lelarge wrote: > Le 19/01/2011 23:51, Guillaume Lelarge a écrit : >> Le 19/01/2011 23:42, Dave Page a écrit : >>> On Wed, Jan 19, 2011 at 10:38 PM, Guillaume Lelarge >>> wrote: Le 16/01/2011 09:32, Dave Page a écrit : > On Sat, Jan 15, 2011 at 11:17 PM, Guillaume Lelarge > wrote: >> Le 15/01/2011 23:58, Josh Berkus a écrit : >>> Nothing showstopping, but: >>> >>> 1) After you make changes in the Server Properties dialog, it gives you >>> the fairly useless message that "Some changes will not take effect until >>> the next time pgAdmin connects to the server". The reason this message >>> is useless (and annoying) is that pgAdmin prevents you from changing >>> those fields unless you are disconnected from the server in the first >>> place. >>> >> >> Yeah, I don't like it either. Need to be fixed. > > Actually, it is correct; you can tweak the DB Restriction, but it > needs a full refresh to take effect. That said, it is inconsistent > from other settings. > > I commited a patch that simply displays the message only when the user is connected to the server. Now, what I would like to know is if the other settings should stay disabled? why only some of them are disabled (or enabled)? shouldn't we just make them all enabled? >>> >>> I'd be inclined to make them all disabled. >>> >> >> When one is connected, right? (if not, we couldn't do much after >> creating it :) ). Which means we would get rid of the message, as a user >> won't be able to change server's settings once connected to it. Makes >> sense to me. Working on it. >> > > Got a patch, but I'm wondering if this is 1.12 material? or is it 1.14 > only? actually, Josh's bug is fixed, so this could be 1.14 only. Any > opinions on this matter? 1.14. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] Minor UI issues for Server Properties dialog box
Le 20/01/2011 00:18, Dave Page a écrit : > On Wed, Jan 19, 2011 at 11:10 PM, Guillaume Lelarge > wrote: >> Le 19/01/2011 23:51, Guillaume Lelarge a écrit : >>> Le 19/01/2011 23:42, Dave Page a écrit : On Wed, Jan 19, 2011 at 10:38 PM, Guillaume Lelarge wrote: > Le 16/01/2011 09:32, Dave Page a écrit : >> On Sat, Jan 15, 2011 at 11:17 PM, Guillaume Lelarge >> wrote: >>> Le 15/01/2011 23:58, Josh Berkus a écrit : Nothing showstopping, but: 1) After you make changes in the Server Properties dialog, it gives you the fairly useless message that "Some changes will not take effect until the next time pgAdmin connects to the server". The reason this message is useless (and annoying) is that pgAdmin prevents you from changing those fields unless you are disconnected from the server in the first place. >>> >>> Yeah, I don't like it either. Need to be fixed. >> >> Actually, it is correct; you can tweak the DB Restriction, but it >> needs a full refresh to take effect. That said, it is inconsistent >> from other settings. >> >> > > I commited a patch that simply displays the message only when the user > is connected to the server. > > Now, what I would like to know is if the other settings should stay > disabled? why only some of them are disabled (or enabled)? shouldn't we > just make them all enabled? I'd be inclined to make them all disabled. >>> >>> When one is connected, right? (if not, we couldn't do much after >>> creating it :) ). Which means we would get rid of the message, as a user >>> won't be able to change server's settings once connected to it. Makes >>> sense to me. Working on it. >>> >> >> Got a patch, but I'm wondering if this is 1.12 material? or is it 1.14 >> only? actually, Josh's bug is fixed, so this could be 1.14 only. Any >> opinions on this matter? > > 1.14. > Done. Thanks. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Re: [pgadmin-support] Issues with large message / history buffers
Le 16/01/2011 23:13, Josh Berkus a écrit : > All, > > When I'm debugging stored procedures, I often will put lots of RAISE > statements in them, sometimes generating hundreds to thousands of lines > of output when I run them. pgAdmin is rather unhappy with this, > dramatically slowing down as the output grows. > > I think that we ought to have a limit of the amount of text in the > message and history panes of the query tool. User-settable, defaulting > to say 1000 rows. Actually, I don't see the point in this. If you want your stored procedures to display so many messages, why would pgAdmin not show them? to stop making it slow, I got this. But if you put so many messages in your stored procedures, it's because you want to see them. So you actually don't want that pgAdmin hides them. > Currently, pgAdmin allows you to set the maximum > number of *queries* but that's not very helpful if each query is > generating thousands of lines of output. > Not helpful because it doesn't have this purpose. Setting maximum of queries is for the combobox, so that you don't end up with 1. a huge "historic queries" file, 2. an unusable "historic queries" combobox. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
