From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Mark Wong <markwkm(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, gabrielle <gorthx(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, David Christensen <david(at)endpoint(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: multiple -f support |
Date: | 2011-02-06 16:16:31 |
Message-ID: | 201102061616.p16GGVR19046@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I assume having psql support multiple -f files is not a high priority or
something we don't want.
---------------------------------------------------------------------------
Mark Wong wrote:
> Hi all,
>
> I took a stab at changing this up a little bit. I pushed the logic
> that David introduced down into process_file(). In doing so I changed
> up the declaration of process_file() to accept an additional parameter
> specifying how many files are being passed to the function. Doing it
> this way also makes use of the logic for the current single
> transaction flag without turning it into dead code.
>
> I also added a check to return EXIT_FAILURE if any error was thrown
> from any of the sql files used, thus stopping execution of any further
> file. Gabrielle tells me the error echoed in this event is not clear
> so there is still a little more work that needs to be done.
>
> Regards,
> Mark
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Urbański | 2011-02-06 16:40:25 | Re: pl/python explicit subtransactions |
Previous Message | Jan Urbański | 2011-02-06 16:14:10 | Re: REVIEW: PL/Python table functions |