On Tuesday 07 April 2009 03:36:43 Tom Lane wrote:
You won't get far with doing it to pg_proc: internal functions *have to*
have entries in there, else the fmgrtab infrastructure for them doesn't
get created. (Yeah, I suppose there are other ways to drive that, but
the fact remains that they
Peter Eisentraut pete...@gmx.net writes:
What is the purpose of fmgrtab anyway?
It's so we can find the addresses of internal functions to call them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thursday 09 April 2009 02:24:53 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
What is the purpose of fmgrtab anyway?
It's so we can find the addresses of internal functions to call them.
Ah yes of course. But then the table can just as well be built by something
based on
Tom Lane t...@sss.pgh.pa.us writes:
So I think that's out. The only alternative that comes to mind is
to have initdb issue an additional SQL command to establish the default
after the bootstrap phase; that is, something like
CREATE OR REPLACE FUNCTION
pg_start_backup(label text, fast
Gregory Stark st...@enterprisedb.com writes:
Well, not that this is appropriate at this moment, but I had been considering
proposing we do this to most of pg_proc and pg_operator. It's really quite a
pain to maintain these files manually, especially pg_operator.
You won't get far with doing it
