Skip site navigation (1) Skip section navigation (2)

Re: Idea: check SQL before copying to SQL dialogue.

From: Erwin Brandstetter <brandstetter(at)falter(dot)at>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Idea: check SQL before copying to SQL dialogue.
Date: 2011-07-21 16:54:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On 20.07.2011 22:45, Guillaume Lelarge wrote:
> On Wed, 2011-07-20 at 21:41 +0200, Erwin Brandstetter wrote:
>> On 20.07.2011 20:26, Guillaume Lelarge wrote:
>>> On Wed, 2011-07-20 at 19:05 +0100, Dave Page wrote:
>>>> On Wed, Jul 20, 2011 at 6:05 PM, Erwin Brandstetter
>>>> <brandstetter(at)falter(dot)at>   wrote:
>>>>> Aloha!
>>>>> A lot of work has been put into when and where to refresh the browser
>>>>> window.
>>>>>   From my experience it is often a _good_ thing, that changes via SQL are not
>>>>> reflected in the browser window immediately. Serves me well as a poor man's
>>>>> undo-tool.
>>>>> On the other hand, one tends to forget about refreshing the browser,
>>>>> especially casual users who are not aware on what occasions the browser's
>>>>> display is refreshed automatically.
>>>>> The major pitfall is with the option "Copy SQL from main form to SQL
>>>>> dialogue" - and most people use that one. If you forget to refresh
>>>>> beforehand, you may lose your most recent changes and may not even notice
>>>>> it.
>>>>> Keeps happening to me.
>>>>> How about this idea?
>>>>> - Whenever the "Copy SQL from main form to SQL dialogue" feature kicks in,
>>>>> check if the displayed SQL is the latest version.
>>>>> - If not, ask the user whether he wants the latest instead. (DO ask!)
>>>>> (We already have a similar check befor saving anything from a properties
>>>>> dialog.)
>>>>> Anybody trying hard enough can still screw up, with copy / paste, for
>>>>> instance. But this idea would take care of the major pitfall for me.
>>>>> Any +1's on this?
>>>> To do that we'd probably need a mechanism for doing quick refreshes at
>>>> any point - this is something we discussed at Char(11), but will
>>>> require fairly significant effort. The hope is to work on it for 1.16.
>>> Well, as we said, the main issue is: should we only refresh the object
>>> you clicked on, or all the objects under it? I mean: if I click on a
>>> schema, should it refresh only the schema's properties and sql pane? or
>>> should it refresh the schema's properties, sql pane and the same for
>>> every objects belonging to the schema? On a schema, I would understand
>>> we only refresh the schema itself and not its objects, because the SQL
>>> pane won't differ. But take a table for example. If we don't refresh the
>>> subobjects (columns, indexes, contraints, rules, triggers), the SQL pane
>>> will be wrong.
>>> So, to me, the two main reasons I'm not working on it is:
>>> 1. I don't have an answer to this question
>>> 2. I don't have time :)
>> I am thinking simple: only check if the SQL pane at hand (the actual text that is copied) reflects the latest version at the time it is copied to the
>> SQL editor. No additional checks.
> Meaning we have to refresh the object properties (and all the sub-items of a table if the object is a table).
>> If the status quo has changed and the user chooses to work with the latest version, then that's what he gets in the SQL editor.
>> I am not even convinced we should refresh the SQL pane at this point. That's not what the user asked for - he may still want the outdated version. I
>> do sometimes.
> Well, if we have the informations, it would be stupid to loose them.

But this is really only a minor point.
1.) Check for updates and make the user aware of them - if any.
2.) Let him chose what to copy to the SQL editor.
3.) Update the object browser while being at it - depending on OR regardless of his pick.

I would go with the user's choice. After a refresh, old information is gone.
If it is substantially easier to refresh objects in question right away, then I can live with that, too. As long as the user can get the old version 
in the SQL editor.

Erwin Brandstetter

In response to

pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2011-07-21 19:44:34
Subject: Re: Altering column collation
Previous:From: Vladimir KokovicDate: 2011-07-21 07:08:41
Subject: Re: Copy/Paste table(s) functions - git context patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group