Re: full featured alter table? - Mailing list pgsql-general

From Jan Wieck
Subject Re: full featured alter table?
Date
Msg-id 3EEE61B9.4030805@Yahoo.com
Whole thread Raw
In response to Re: full featured alter table?  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: full featured alter table?  (Greg Stark <gsstark@mit.edu>)
List 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@Yahoo.com #


pgsql-general by date:

Previous
From: Joseph Shraibman
Date:
Subject: order of nested loop
Next
From: Tom Lane
Date:
Subject: Re: order of nested loop