Re: C language function dump problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: C language function dump problem
Date
Msg-id 28968.963163543@sss.pgh.pa.us
Whole thread Raw
In response to C language function dump problem  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Re: C language function dump problem
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> It seems some code disappeared from pg_dump.c between 7.0.2 and current,
> ...
> P.S. The specific problem is that it now uses plsrc as the definition for
> all functions, whereas the (C language) plpgsql call handler requires plbin
> to be used.

Looks like I broke it :-(.  Didn't read the code carefully enough,
I guess, and thought that the selection of language name was the only
useful thing it was accomplishing.  So I figured the default path would
handle all cases just as easily.

Now that I think about it, the code was actually broken before that,
because for a C-language function it needs to produce two AS items
specifying the link symbol and the library path.  Looks like we
neglected to update pg_dump when that feature was added.

Basically you need to make pg_dump do the inverse of
interpret_AS_clause() in src/backend/commands/define.c.  Note that
there are now two OIDs that need to be handled this way, ClanguageId
and NEWClanguageId.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: initdb and runcheck problems (Latest CVS)
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] Unnexpected results using to_number()