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

Sorry - missed that. I generally prefer to only include SQL DDL for
things that are non-default.

On Fri, May 7, 2010 at 6:43 PM, Erwin Brandstetter
<brandstetter(at)falter(dot)at> wrote:
> 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
>
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company