From: | Ian Lance Taylor <ian(at)airs(dot)com> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Support for %TYPE in CREATE FUNCTION |
Date: | 2001-05-30 19:22:30 |
Message-ID: | siitiiy749.fsf@daffy.airs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Jan Wieck <JanWieck(at)Yahoo(dot)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?
Ian
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2001-05-30 20:00:00 | Re: Support for %TYPE in CREATE FUNCTION |
Previous Message | Jan Wieck | 2001-05-30 19:11:48 | Re: Cache for query plans |
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2001-05-30 20:00:00 | Re: Support for %TYPE in CREATE FUNCTION |
Previous Message | The Hermit Hacker | 2001-05-30 19:21:38 | Re: Patch to remove sort files, temp tables, unreferenced files |