Re: pg_get_triggerdef in pg_dump - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: pg_get_triggerdef in pg_dump
Date
Msg-id 3EF04618.5000201@web.de
Whole thread Raw
In response to Re: pg_get_triggerdef in pg_dump  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: pg_get_triggerdef in pg_dump  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Hi Christopher,

>Sorry if I offended you.
>
I wasn't offended because I wasn't sure what you wanted to say to me. 
You may call me the biggest fool of all, as long you do it in Sualheli, 
or Korean... :-)

>  'You what!' is what you say when you cannot
>believe what someone is saying...  Calling 'stable views that work when
>you rename columns' a gimmick is quite an incredible thing to say...
>
>You honestly would rather be able to view accurate source of views that
>don't work rather than complicted source of views that actually work?
>
Yes, that's right. I've been working this way for years, and all MSSQL 
users do because there's no other way for them.
These automatic name change propagation is very limited, concerning all 
possible changes you can have in a table.

- drop column -> will restrict now, or need cascade
- rename column -> propagates to plan tree, why not restrict or require 
cascaded to drop source?
- alter column size/type -> not possible, need to create alternate 
column, drop old (which is restricted...) and rename

You see, only few changes that can be done are handled at the moment.

In my experience with large and complicated data models, I found that I 
hardly ever would rename a table or a column. There's nothing like an 
automatic column name update of applications... After years, it's hard 
to tell where everything's used, especially if queries are created at 
runtime.
I consider a view more as being a part of an application, rather than 
part of the data model (unless rules are used), and thus the same 
problems apply.

What I need again and again, is changing the size of a column (rarely 
the type). For pgsql, I'd have to drop the column, and need to recreate 
all views. For MSSQL, it won't matter if the column is dropped/recreated 
or just resized, the view won't notice until it's used again.

>Anyway, there's no reason why we can't have both with a bit of effort...
>  
>
This certainly would be nice, maybe there could be back-pointers from 
nodes into the source so identifier names can be identified and 
modified? Just like debugging-enabled code has references to the source.

Another way could be storing the source in a translated form, like
SELECT X.($88012.1) FROM $88012 AS X
instead of
SELECT X.bar FROM public.foo AS X


Regards,
Andreas



pgsql-hackers by date:

Previous
From: Christof Petig
Date:
Subject: Re: Extending PostgreSQL in C or C++
Next
From: Tom Lane
Date:
Subject: Re: O_DIRECT in freebsd