Re: Support for %TYPE in CREATE FUNCTION

Jan Wieck <JanWieck@Yahoo.com> writes:

>     What you describe above is a general schema  change  callback
>     entry  point  into  a  procedural  language  module. It get's
>     called at CREATE/DROP FUNCTION and any other catalog change -
>     right? And the backend loads all declared procedural language
>     handlers at startup time so they can  register  themself  for
>     callback  -  right? Sound's more like a bigger project than a
>     small grammar change.

Yes.  But since it doesn't look like the small grammar change will get
into the sources, the bigger project appears to be needed.

>     I don't say we shouldn't have support for %TYPE.  But  if  we
>     have  it, ppl will assume it tracks later schema changes, but
>     with what I've seen so far it either could have  severe  side
>     effects  on  other languages or just doesn't do it.  A change
>     like %TYPE support is a little too fundamental  to  get  this
>     quick yes/no decision just in a few days.

Understood.  I don't need a quick yes/no decision on the patch--after
all, I submitted it a month ago.

What would help a lot, though, is some indication of whether this
patch is of interest.  Should I put the time into doing something
along the lines that I outlined?  Would that get accepted?  Or would I
be wasting my time, and should I just keep my much simpler patch as a
local change?

I've been doing the free software thing for over a decade, both as a
contributor and as a maintainer, with many different projects.  For
any given functionality, I've normally been able to say ``this would
be good'' or ``this would be bad'' or ``this would be too hard to
maintain'' or ``this is irrelevant, but it's OK if you do all the
work.''  I'm having trouble getting a feel for how Postgres
development is done.  In general, I would like to see a roadmap, and I
would like to see where Oracle compatibility falls on that roadmap.
In specific, I'm trying to understand what the feeling is about this
particular functionality.

Ian