Re: "Compact" and "complete" SQL (was: Re: Redundant statements)
От | Dave Page |
---|---|
Тема | Re: "Compact" and "complete" SQL (was: Re: Redundant statements) |
Дата | |
Msg-id | l2w937d27e11005071221x563211f4l5ce4ebbec2a3bbc@mail.gmail.com обсуждение исходный текст |
Ответ на | "Compact" and "complete" SQL (was: Re: Redundant statements) (Erwin Brandstetter <brandstetter@falter.at>) |
Ответы |
Re: "Compact" and "complete" SQL
(Erwin Brandstetter <brandstetter@falter.at>)
|
Список | pgadmin-hackers |
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@falter.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@lelarge.info wrote: >> >> Le 29/04/2010 17:28, Erwin Brandstetter a écrit : >> >>> >>> On 29.04.2010 15:21, guillaume@lelarge.info wrote: >>> >>>> >>>> Le 29/04/2010 14:15, Erwin Brandstetter a écrit : >>>> >>>> >>>>> >>>>> On 28.04.2010 19:16, brandstetter@falter.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@postgresql.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
В списке pgadmin-hackers по дате отправления:
Предыдущее
От: Erwin BrandstetterДата:
Сообщение: "Compact" and "complete" SQL (was: Re: Redundant statements)
Следующее
От: svn@pgadmin.orgДата:
Сообщение: SVN Commit by guillaume: r8351 - trunk/pgadmin3/pgadmin/frm