Re: pg_get_triggerdef in pg_dump

From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_get_triggerdef in pg_dump
Date: 2003-06-18 10:59:36
Message-ID: 3EF04618.5000201@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-18 14:00:48 Re: O_DIRECT in freebsd
Previous Message Christof Petig 2003-06-18 10:57:45 Re: Extending PostgreSQL in C or C++