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
