From: | James William Pye <pgsql(at)jwp(dot)name> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_proc probin misuse |
Date: | 2006-05-27 21:17:22 |
Message-ID: | 20060527211722.GB54336@lit.jwp.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 26, 2006 at 11:21:32PM -0400, Tom Lane wrote:
> James William Pye <pgsql(at)jwp(dot)name> writes:
> > So is this "fix your broken PL" or "pg_dump should only be doing that for C
> > language functions"?
>
> Offhand it seems to me that pg_dump is behaving reasonably: it's storing
> probin if it sees something there to be stored. The asymmetry is in the
> backend, specifically functioncmds.c's interpret_AS_clause(): it has a
> hardwired assumption that probin is only relevant to C functions.
>
> Feel free to propose a saner definition. AFAICS the current coding
> makes probin useless for all except C functions, so I think it could
> be improved.
I guess there are two ways to go about it. Simply remove the assumption that
probin is only relevant to C functions; perhaps allowing a hardwired exception
for builtin languages where allowing probin to be set would be deemed unsightly
(ie, the easy way ;). Or, add a column to pg_language that specifies the
language's probin usage so that pg_dump and the backend have an idea of how to
handle these things for the given language(the "takes a bit more work" way).
[I imagine the former could gracefully lead into the latter as well.]
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2006-05-27 21:31:31 | Re: anoncvs still slow |
Previous Message | Tom Lane | 2006-05-27 20:53:29 | Re: Better to dump tabs as tabs, or \t? |