On Thursday 09 April 2009 02:24:53 Tom Lane wrote:
> Peter Eisentraut 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 rgrep PG_FUNC
Peter Eisentraut 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 subscription:
http:/
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 the
Gregory Stark 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 to pg_proc: interna
Tom Lane 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 boolean DEFAULT
