Re: Support for %TYPE in CREATE FUNCTION - Mailing list pgsql-hackers
From | Jan Wieck |
---|---|
Subject | Re: Support for %TYPE in CREATE FUNCTION |
Date | |
Msg-id | 200105302102.f4UL2i608063@jupiter.us.greatbridge.com Whole thread Raw |
In response to | Re: Support for %TYPE in CREATE FUNCTION (Ian Lance Taylor <ian@airs.com>) |
Responses |
Re: Support for %TYPE in CREATE FUNCTION
|
List | pgsql-hackers |
Ian Lance Taylor wrote: > Jan Wieck <JanWieck@Yahoo.com> writes: > > > What most of those if favor for doing it right now want is an > > easy Oracle->PostgreSQL one-time porting path. Reasonable, > > but solveable with some external preprocessor/script too. > > Can you explain how an external preprocessor/script addresses the > issue of %TYPE in a function definition? Presumably the preprocessor > has to translate %TYPE into some definite type when it creates the > function. But how can a preprocessor address the issue of what to do > when the table definition changes? There still has to be an entry in > pg_proc for the procedure. What happens to that entry when the table > changes? > > You seem to be saying that %TYPE can be implemented via some other > mechanism. That is fine with me, but how would that other mechanism > work? Why it would not raise the exact same set of issues? What I (wanted to have) said is that the "one-time porting" can be solved by external preprocessing/translation of %TYPE into the resolved type at porting time. That is *porting* instead of making the target system emulate the original platform. You know, today you can run a mainframe application on an Intel architecture by running IBM's OS390 emulator under Linux - but is that porting? And I repeat what I've allways said over the past years. I don't feel the need for all the catalog mucking with most of the ALTER commands. Changing column types here and there, dropping and renaming columns and tables somewhere else and kicking the entire schema while holding data around during application coding doesn't have anything to do with development or software engineering. It's pure script-kiddy hacking or even worse quality. There seems to be no business process description, no data model or any other "plan", just this "let's codearound until something seems to work all of the sudden". Where's the problem description, application spec,all the stuff the DB schema resulted from? Oh - it resulted from "I need another column because I have this unexpected value I need to keep - and if there'll be more of them I can ALTER it to be an array". Well, if that'swhat people consider "development", all they really need is ALTER n% OF SCHEMA AT RANDOM; Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
pgsql-hackers by date: