Обсуждение: Update functions and trigger functions by clicking
Hello, I implemented an option to update functions and trigger functions, by clicking on them in the treeview. This avoids problems when someone changes the function, and I get the old version and then overwrite it, without reminding me from updating (F5) before. I did a checkbox in the form of options. This would be useful for everyone? Thanks. Excuse my English "Google Translate"
Hi On Fri, May 27, 2011 at 1:57 AM, Vinicius Santos <vinicius.santos.lista@gmail.com> wrote: > Hello, > > I implemented an option to update functions and trigger functions, by > clicking on them in the treeview. > > This avoids problems when someone changes the function, and I get the old > version and then overwrite it, without reminding me from updating (F5) > before. > > I did a checkbox in the form of options. > > This would be useful for everyone? Certainly interested to see it, though we may not want to apply it as is to avoid inconsistent behaviour between different object types on the treeview that may end up confusing people. What I'd really like to see is an option which enables on-selection refreshing for all object types. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
What I'd really like to see is an option which enables on-selection
refreshing for all object types.
OK.
I will develop it , and send a patch for you to analyze.
Thanks.
On Fri, May 27, 2011 at 11:57 AM, Vinicius Santos <vinicius.santos.lista@gmail.com> wrote: >> >> What I'd really like to see is an option which enables on-selection >> refreshing for all object types. >> > > OK. > > I will develop it , and send a patch for you to analyze. Cool, thanks :-). Ideally, something like this should be implemented in an object type independent way - ie. in pgObject for example. Not sure how feasible that is though... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Cool, thanks :-). Ideally, something like this should be implemented
in an object type independent way - ie. in pgObject for example. Not
sure how feasible that is though...
I thought just in pgObject.
I'll write and tell me what you think.
Should I send this afternoon (afternoon for me, here in Brazil) :-)
Thanks.
I'll write and tell me what you think.
Should I send this afternoon (afternoon for me, here in Brazil) :-)
Thanks.
Le 05/27/2011 02:08 PM, Vinicius Santos a écrit : > Cool, thanks :-). Ideally, something like this should be implemented > >> in an object type independent way - ie. in pgObject for example. Not >> sure how feasible that is though... >> >> I thought just in pgObject. > > I'll write and tell me what you think. > > Should I send this afternoon (afternoon for me, here in Brazil) :-) > Take your time, there's no need to hurry. Our current HEAD is frozen (for new features, that is). It won't get applied anytime soon. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Fri, May 27, 2011 at 12:08 PM, Vinicius Santos <vinicius.santos.lista@gmail.com> wrote: > Cool, thanks :-). Ideally, something like this should be implemented >> >> in an object type independent way - ie. in pgObject for example. Not >> sure how feasible that is though... >> > I thought just in pgObject. > > I'll write and tell me what you think. > > Should I send this afternoon (afternoon for me, here in Brazil) :-) You have plenty of time - we haven't branched 1.14 yet, so nothing will be committed for a little while at least. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
>>> in an object type independent way - ie. in pgObject for example. Not >>> sure how feasible that is though... Hello, It could take a look at my patch? I thought of other ways to implement, but I ended up with this. Thanks.
On Mon, May 30, 2011 at 1:58 AM, Vinicius Santos <vinicius.santos.lista@gmail.com> wrote: >>>> in an object type independent way - ie. in pgObject for example. Not >>>> sure how feasible that is though... > > Hello, > > It could take a look at my patch? > > I thought of other ways to implement, but I ended up with this. Hi, That seems pretty simple, but I think it misses one of the big issues - avoiding pushing the refresh down the entire tree. As an example, consider what happens if you click on a schema. As the code stands, it looks like it'll cause not only the schema to be refreshed, but all of the sub-objects that are currently populated on the tree. That could make that click very expensive. I think we need to find a way to ensure that the refresh is constrained to the appropriate subset of objects - for a table, that will probably include some of the sub-objects (eg. columns), for a schema, just the schema itself. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi, sorry for the delay in responding. I agree to share with you. First, the update will be different for "F5 refresh" and per "click refresh". This could confuse people. Second, this does not obviate the problem of another user to create, for example, a table and this table does not appear to me. In other words, I think my Schema is completely updated, when in fact it is not. What do you think? Again, I do not know the translation is perfect.
On Sat, Jun 4, 2011 at 8:05 PM, Vinicius Santos <vinicius.santos.lista@gmail.com> wrote: > > Hi, sorry for the delay in responding. > > I agree to share with you. > > First, the update will be different for "F5 refresh" and per "click > refresh". This could confuse people. I don't think so - there's a pretty obvious difference between refreshing the tree on selection of a menu option or button click, and simply refreshing the object that's selected. > Second, this does not obviate the problem of another user to create, for > example, a table and this table does not appear to me. No. it doesn't. > In other words, I think my Schema is completely updated, when in fact it > is not. > > What do you think? Updating the entire schema (it may well be that much, if everything is expanded) is going to be far too expensive on anything but the smallest database on a very fast machine. We have users with schemas ranging from a handful to tens or even hundreds of thousands of objects - for most them, refreshing a whole schema hierarchy on every click is not an option. I'd probably be happy with a patch that offered *both* "refresh object on click" and "refresh object and children on click", but not just the latter - the use case is just too narrow imho. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I'd probably be happy with a patch that offered *both* "refresh object
on click" and "refresh object and children on click", but not just the
latter - the use case is just too narrow imho.
I agree with you.
What do you think of a ComboBox with the two options?
I'll start to develop, and sending the patch in a few weeks, so you take a look.
Thanks.
On Tue, Jun 7, 2011 at 1:51 AM, Vinicius Santos <vinicius.santos.lista@gmail.com> wrote: >> >> I'd probably be happy with a patch that offered *both* "refresh object >> on click" and "refresh object and children on click", but not just the >> latter - the use case is just too narrow imho. >> > > I agree with you. > > What do you think of a ComboBox with the two options? Sure. Three options though - don't forget to keep the current behaviour as an option. > I'll start to develop, and sending the patch in a few weeks, so you take a > look. Thanks! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company