Re: [PATCH] "\ef <function>" in psql

From: Abhijit Menon-Sen <ams(at)oryx(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gavin Sherry <swm(at)alcove(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] "\ef <function>" in psql
Date: 2008-07-23 09:56:43
Message-ID: 20080723095643.GA11528@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 2008-07-17 18:28:19 -0400, tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
>
> It wouldn't take a whole lot to convince me that a pg_get_functiondef
> would be useful, although I don't foresee either of those applications
> wanting to use it because of their backward-compatibility constraints.

If the code lives in psql (as with my patch), then it has some chance of
working with older servers, but if you're happy with pg_get_functiondef,
then I'm happy enough to use it to get \ef working. I agree that pg_dump
wouldn't want to use it, of course, but I guess it doesn't matter very
much if \ef doesn't work on older servers.

What would the function return? "CREATE OR REPLACE FUNCTION ..."? Would
that be good enough for everyone who might want to call it?

(BTW, psql from 8.3 is already somewhat broken with 8.1:

archiveopteryx=> \d access_keys
ERROR: column i.indisvalid does not exist

And 8.2 as well:

archiveopteryx=> \d access_keys
ERROR: column t.tgconstraint does not exist
LINE 3: WHERE t.tgrelid = '16847' AND t.tgconstraint = 0
^
Oh, I see they've both been fixed in CVS. Sorry for the noise.)

-- ams

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2008-07-23 10:31:31 Re: Postgres-R: internal messaging
Previous Message Marko Kreen 2008-07-23 09:48:09 Re: [patch] plproxy v2