Re: full featured alter table?

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: full featured alter table?
Date: 2003-06-17 00:32:57
Message-ID: 3EEE61B9.4030805@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greg Stark wrote:
> Bleagh. what a way to create tons of extra work for nothing. So now every time
> I add a new attribute to an existing entity I not only have to create the new
> column in the table, and create the new presentation code to handle the
> attribute, I not only have to check through all the queries that fetch the
> data for presentation and add the columns there, I now have to also check
> through all the views those queries use and add the columns there as well?
>
> The goal here is to avoid having to adjust ten million places every time you
> make a minor change to internal data. It's the whole reason ADTs and objects
> were invented. To avoid having to have every piece of code know the internals
> of every data type. What all the attributes of an entity are is just such an
> internal that should be hidden from code that doesn't need it. Unfortunately
> the best SQL can do on that front is SELECT * and even that doesn't work too
> well. But it's better than hard coding explicit lists of attributes everywhere
> throughout the application.

You don't get the point, Greg. In all "applications" I have seen so far,
the number of places where the code analyzes the attributes actually
returned from a SELECT * for display purposes vs. the number of places
where the application code needs explicit fields from one or more tables
tends to be highly in favor for the latter. You know any example to the
contrary out of the top of your head?

If one needs to add attributes that often and has that many places in
his code that need to look what they got after something else blindly
selected whatever that table looks like today ... IMHO that's an
indicator for two things.

1. He doesn't know that a developer is supposed to write a concept
and a specification before dragging and dropping around like a
berserk in some graphical design toy.

2. His code prooves that he doesn't remember what he coded last
week and all the reusability of code, OO was supposed to give
us, is lost in the growing address space of his applications.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-06-17 00:55:52 Re: order of nested loop
Previous Message Joseph Shraibman 2003-06-17 00:30:56 order of nested loop