"Compact" and "complete" SQL (was: Re: Redundant statements)

Hi Dave!

I send a reply on the thread to you, Dave. Guillaume seems to like the
idea somewhat. I wonder what you think about it.

On 29.04.2010 17:50, guillaume(at)lelarge(dot)info wrote:
> Le 29/04/2010 17:28, Erwin Brandstetter a écrit :
>
>> On 29.04.2010 15:21, guillaume(at)lelarge(dot)info wrote:
>>
>>> Le 29/04/2010 14:15, Erwin Brandstetter a écrit :
>>>
>>>
>>>> On 28.04.2010 19:16, brandstetter(at)falter(dot)at wrote:
>>>>
>>>>
>>>>> Aloha!
>>>>>
>>>>> I am testing Guillaume's version of pgadmin3.exe from Apr. 17.
>>>>>
>>>>> The fix below is included and it seems to fix the problem just fine.
>>>>> However, as a side effect (?) there is now a redundant statement for
>>>>> each and every column:
>>>>> ALTER TABLE foo ALTER COLUMN bar SET STORAGE PLAIN;
>>>>> or
>>>>> ALTER TABLE foo ALTER COLUMN baz SET STORAGE EXTENDED;
>>>>>
>>>>> I think those statements should only be included, if the storage type
>>>>> differs from the default setting - like "SET STATISTICS" is handled
>>>>> now.
>>>>> It is pretty noisy as it is now.
>>>>>
>>>>>
>>> (...)
>>>>> On a side note: I would handle "WITH (OIDS=FALSE)" for table
>>>>> definitions likewise: only print it, if it differs from the default
>>>>> setting.
>>>>>
>>>>>
>>> If we do this, a user won't be able to copy the SQL and paste/execute it
>>> on another server if this one has another value for default_with_oids.
>>> So, I'm against its removal (unless someone could prove I'm wrong :) ).
>>>
>>>
>> As it is now, the policy is somewhat unclear. Some elements are added
>> even though they are redundant under the local settings, others are not.
>> If we could switch between complete and compact display, this would help
>> to clear the situation.
>>
> +1
>
>
>> In my daily work I reuse code in the same db cluster 99% of the time -
>> 95% of the time in the same db. Redundant SQL is only cluttering the
>> display and slows me down on a regular basis.
>> One or the other redundant key word should not hurt, but we could strip
>> most of the noise. (Reduces traffic a bit, too.)
>> For cases where we want to copy objects to a different environment, the
>> option "complete SQL" should be an improvement, too.
>>
>> I would define "local settings" as what "SHOW ALL" returns for the
>> current connection (database / user defaults are in effect).
>>
> OK.
>
>
>>>> Maybe an option "Show complete SQL"? To switch between "complete"
>>>> (noisy) and default display (only what is necessary to create an
>>>> identical object with the current settings).
>>>> Personally I am only interested in the "compact" version, but other
>>>> people's preferences may vary?
>>>>
>>>>
>>> I'm not sure about this either. How could a user know about the
>>> differences between a complete and a partial SQL?
>>>
>>>
>> We could have a note at the very top (possibly optional., too):
>> -- SQL complete
>> -- SQL for current connection
>> Current settings are defined by the connection parameters displayed in
>> the toolbar: host, user, database.
>>
>>
> Seems better to me.
>

In pg 9.0 we might also want to take default ACLs for the database /
schema into consideration. But this can be optional.
In a first approach we could provide a full set of GRANT / REVOKE
statements in both verions. Trim the "compact" version according to
default ACLs later.
It might be an additional source for the definition of the "current"
connection, though - besides host, database and user.

>>>> This would be a major wishlist item. Not complicated, but possibly many
>>>> lines of code.
>>>>
>>>>
>>> Well, actually, the only thing I think is needed here is to display (or
>>> not) some column's properties. Not complicated, not a lot of code.
>>>
>>>
>> Even better. :) But there are probably a number of cases, where we might
>> want to add SQL to the "complete" version or trim in the "compact" version.
>>
>>
> Sure. We'll need complete details on these cases :)
>

We could start by cloning the status quo, and then add statements /
clauses to the complete version and trim redundant stuff from the
compact version step by step. This way the kickoff would be simple.

> (...)
>> The option to switch between "complete" and "compact" is a different
>> (more fundamental) feature. I would like it a lot, but I am not coding,
>> so I can only suggest.
>>
>>
> You can also create a ticket on this. But I'll refrain working on this,
> waiting for Dave's opinion on this issue. And it probably won't be for
> 1.12, as beta will begin in a few days.

OK, most likely not for pgAdmin 1.12. Maybe for the next release? Next
point release if the changes to the code base are not too invasive?

So, what do you think of the idea, Dave? I would love the "compact"
version, while I would be happy about the "complete" version on
occasions, too.
Depending on your answer I would add a writeup of the feature as a
wishlist item in trac.

Regards
Erwin