Re: C language function dump problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: C language function dump problem
Date: 2000-07-09 17:25:43
Message-ID: 28968.963163543@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner <pjw(at)rhyme(dot)com(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-07-09 17:38:52 Re: Unnexpected results using to_number()
Previous Message Bruce Momjian 2000-07-09 16:38:42 Re: initdb and runcheck problems (Latest CVS)