Prev: Building under Visual Studio 2008 - pqcomm.c compile error
Next: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
From: Tom Lane on 15 Jul 2008 10:33 Abhijit Menon-Sen <ams(a)oryx.com> writes: > Refactoring pg_dump was more work than I had time to do right now, and I > wanted \ef to work, so I hacked up the attached (by copying dumpFunc and > its dependencies to src/bin/psql/dumpfunc.[ch]). I doubt we'd consider accepting a patch done this way. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Abhijit Menon-Sen on 15 Jul 2008 10:58 At 2008-07-15 10:33:02 -0400, tgl(a)sss.pgh.pa.us wrote: > > I doubt we'd consider accepting a patch done this way. Yes, it's much too ugly to live. I was posting it only for the record, I should have made that clear. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Abhijit Menon-Sen on 17 Jul 2008 14:47 At 2008-07-15 20:28:39 +0530, ams(a)oryx.com wrote: > > > I doubt we'd consider accepting a patch done this way. > > Yes, it's much too ugly to live. Though I must say it would have been even MORE horrible to copy all this code into the backend to make pg_get_functiondef(), notwithstanding the extra utility of a generally-callable function. But what I'm wondering, since Gavin said he once had a working version of this patch (i.e. \ef) which he somehow lost, is how he approached the problem at the time. Gavin? Do you remember? Was it horrible? -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 17 Jul 2008 18:28 Abhijit Menon-Sen <ams(a)oryx.com> writes: > Though I must say it would have been even MORE horrible to copy all this > code into the backend to make pg_get_functiondef(), notwithstanding the > extra utility of a generally-callable function. FWIW, I just found myself forced to invent pg_get_function_arguments() and pg_get_function_result(), because the TABLE function patch has pushed the complexity of printing function argument and result types well beyond the bounds of sanity. (Pavel had hacked up pg_dump and ignored psql's \df ...) 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Abhijit Menon-Sen on 23 Jul 2008 05:56 At 2008-07-17 18:28:19 -0400, tgl(a)sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 Prev: Building under Visual Studio 2008 - pqcomm.c compile error Next: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED |