Re: pg_get_triggerdef in pg_dump
От | Bruce Momjian |
---|---|
Тема | Re: pg_get_triggerdef in pg_dump |
Дата | |
Msg-id | 200306240241.h5O2f5F10911@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_get_triggerdef in pg_dump (Andreas Pflug <Andreas.Pflug@web.de>) |
Ответы |
Re: pg_get_triggerdef in pg_dump
Re: pg_get_triggerdef in pg_dump |
Список | pgsql-hackers |
OK, added to TODO: Modify pg_get_triggerdef() to take a boolean to pretty-print,and use that as part of pg_dump along with psql Andreas, can you work on this? I like the idea of removing extra parens, and merging it into the existing code rather than into contrib makes sense. --------------------------------------------------------------------------- Andreas Pflug wrote: > Tom Lane wrote: > > > > >I recall objecting to someone who wanted to remove "unnecessary" > >parentheses, but I can't see any risk in inserting unnecessary > >whitespace. > > > That "someone" was me indeed, and as I mentioned the code is completely > separated from the code that pg_dump uses. Thus, there's *no way* that > this could break backup integrity. I consider these original functions > as pg_dump helper functions, not meant to be human readable. > > There are *many* parentheses that are not necessary, and the code trying > to figure out is quite conservative. All is decided in one single > routine, depending on two parameters only, and thus failing to locate > several cases when parentheses would be avoidable (not even */ over +- > will be noticed!). > > I've been trying hard to make pgsql as maintainable as mssql, and > there's only this point left. Any attempts to contribute this so far > just have been answered with "dunno but there might eventually perhaps > maybe some problem" without having a look at that function. I feel that > I am asked to prove the validity of my code, which is as impossible as > it is for software in general, but I haven't seen any case where my > solution failed to reproduce correctly. If you know one, tell me. If you > know a case where my core routine decides falsely, tell me. > > What I *really* want is having the original source stored, including > comments, version info, ... Currently, it's argued that underlying table > and column might change, braking the view/rule. This could be > restricted, or source could be dropped (alter table ... cascaded). Is it > really only me who tries to put complicated views into pgsql and wants > to understand them 10 days later? We do have an enterprise grade RDBMS, > don't we? > > Regards, > Andreas > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: