Re: [HACKERS] Explicit psqlrc
2010/3/6 Tom Lane t...@sss.pgh.pa.us: Peter Eisentraut pete...@gmx.net writes: I can see the environment variable variant as an analogy to BASH_ENV, but what is the use case for the --psqlrc option? Wouldn't it be easier and more useful to just be able to process more than one file, say by specifying -f more than once? The analogy I was thinking about was psql -X, but I agree that it's not obvious why this shouldn't be thought of as an additional -f file. Uh, I don't follow. When we use -f, we'll run the script and then exit. The whole point is to run it and *not* exit, since you are normally using it to set up the environment in psql. That said, it might certainly be useful to be able to process more than one file with -f, but that's a different usecase, I think. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
Magnus Hagander mag...@hagander.net writes: 2010/3/6 Tom Lane t...@sss.pgh.pa.us: The analogy I was thinking about was psql -X, but I agree that it's not obvious why this shouldn't be thought of as an additional -f file. Uh, I don't follow. When we use -f, we'll run the script and then exit. The whole point is to run it and *not* exit, since you are normally using it to set up the environment in psql. If we were going to support multiple -f options, it would be sensible to interpret -f - as read from stdin until EOF. Then you could interleave prepared scripts and stdin, which could be pretty handy. The default behavior would be equivalent to a single instance of -f -, and what you are looking for would be -X -f substitute-psqlrc -f -. I do think this is potentially cleaner and more general than the --psqlrc switch. Maybe that should be reverted and the whole topic reconsidered during 9.1 devel cycle. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
2010/3/7 Tom Lane t...@sss.pgh.pa.us: Magnus Hagander mag...@hagander.net writes: 2010/3/6 Tom Lane t...@sss.pgh.pa.us: The analogy I was thinking about was psql -X, but I agree that it's not obvious why this shouldn't be thought of as an additional -f file. Uh, I don't follow. When we use -f, we'll run the script and then exit. The whole point is to run it and *not* exit, since you are normally using it to set up the environment in psql. If we were going to support multiple -f options, it would be sensible to interpret -f - as read from stdin until EOF. Then you could interleave prepared scripts and stdin, which could be pretty handy. The default behavior would be equivalent to a single instance of -f -, and what you are looking for would be -X -f substitute-psqlrc -f -. Right, that would work. Though it would be a lot more user-unfriendly for such a simple thing, IMHO. Also, -f - and just psql behaves different today (for example, in the showing of startup banners). So we couldn't do that without changing the behaviour of at least one of those. Which may not be a problem of course, but I'm sure someone will find a place to complain :) With your interleave, you mean things like psql -f first.sql -f - -f second.sql? That does sound like it could be handy - and also really dangerous :-) I do think this is potentially cleaner and more general than the --psqlrc switch. Maybe that should be reverted and the whole topic reconsidered during 9.1 devel cycle. More general, definitely. But cleaner? I'd say rather the opposite. In the end, I don't see why we can't have both when the implementation is so trivial. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
Magnus Hagander mag...@hagander.net writes: 2010/3/7 Tom Lane t...@sss.pgh.pa.us: If we were going to support multiple -f options, it would be sensible to interpret -f - as read from stdin until EOF. Right, that would work. Though it would be a lot more user-unfriendly for such a simple thing, IMHO. If the issue had come up even once before in psql's existence, I might think that user-friendliness would be a good argument. As things stand, I don't believe the average user will care about it in the least. I'd be willing to lay long odds that the average user doesn't even have a .psqlrc file, much less feel the need to override it. I'd rather see use a substitute psqlrc be a behavior you can build out of existing general-purpose switches than still another option that has to be documented and remembered. Also, -f - and just psql behaves different today (for example, in the showing of startup banners). Yes, there would be some things to think about there, which is why it's a topic for a new devel cycle rather than something to shoehorn in after the close of the last CF. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
2010/3/7 Tom Lane t...@sss.pgh.pa.us: Magnus Hagander mag...@hagander.net writes: 2010/3/7 Tom Lane t...@sss.pgh.pa.us: If we were going to support multiple -f options, it would be sensible to interpret -f - as read from stdin until EOF. Right, that would work. Though it would be a lot more user-unfriendly for such a simple thing, IMHO. If the issue had come up even once before in psql's existence, I might think that user-friendliness would be a good argument. As things stand, I don't believe the average user will care about it in the least. I'd be willing to lay long odds that the average user doesn't even have a .psqlrc file, much less feel the need to override it. I'd rather see use a substitute psqlrc be a behavior you can build out of existing general-purpose switches than still another option that has to be documented and remembered. I've heard if a couple of times before, but I agree it's certainly not a much asked-for one. Most if it has been in off-list scenarios and people have probabliy just thought it's not a big enough feature to bother emailing about. Also, -f - and just psql behaves different today (for example, in the showing of startup banners). Yes, there would be some things to think about there, which is why it's a topic for a new devel cycle rather than something to shoehorn in after the close of the last CF. Fair enough. I expected it to be a small and noncontroversial thing, but since there are objections, I'll go revert it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
Magnus Hagander wrote: Also, -f - and just psql behaves different today (for example, in the showing of startup banners). Yes, there would be some things to think about there, which is why it's a topic for a new devel cycle rather than something to shoehorn in after the close of the last CF. Fair enough. I expected it to be a small and noncontroversial thing, but since there are objections, I'll go revert it. Do you want to create a TODO entry for this? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core dump running PL/Perl installcheck with bleadperl [PATCH]
Tim Bunce tim.bu...@pobox.com writes: I encountered a core dump running PL/Perl installcheck with a very recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl. The cause is a subtle difference between SvTYPE(sv) == SVt_RV and SvROK(sv). The former is checking a low-level implementation detail while the later is directly checking does this sv contains a reference. Hmm. Seems like this patch begs the question: if checking SvTYPE(*svp) isn't safe, why is it safe to look at SvTYPE(SvRV(*svp))? Shouldn't the tests against SVt_PVHV be made more abstract as well? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: incorrect exit code from psql with single transaction + violation of deferred FK constraint
Dominic, sorry you didn't get any reply to your bug report from October,
but it was picked up by Robert Haas in January:
http://archives.postgresql.org/pgsql-hackers/2010-01/msg00478.php
and is now listed as an outstanding 9.0 bug:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
What your bug report illustrates is that the BEGIN/COMMIT commands that
are used for psql -1 are not properly checking for return values. In
fact we are not even properly clearing their libpq result structures.
The deferrable initially deferred clause is causing the file to fail
on the commit, and lacking proper error checking, you are getting a zero
return value from psql.
The attached patch checks for the proper return from BEGIN/COMMIT, and
properly frees the libpq structures. In testing, this does return 3 as
you expected.
---
Dominic Bevacqua wrote:
Hi
I've noticed that executing a sql script such with psql with -1
-vON_ERROR_STOP=on where the script causes a deferred foreign key
constraint to be violated returns 0 rather than the expected 3. I have
reproduced this in psql 8.4.1, 8.3.3 and 8.2.9, which does lead me to
wonder whether it is expected behaviour. However...
Sample code to reproduce:
-- test.sql
create table foo (id int primary key, foo_id int);
alter table foo add constraint fk1 foreign key (foo_id) references
foo(id) deferrable initially deferred;
insert into foo select 1,2;
for which:
psql -1 -vON_ERROR_STOP=on -f test.sql
returns 0 (but with message detailing the constraint violation)
psql -vON_ERROR_STOP=on -f test.sql
returns 3 (as expected).
However, with the constraint immediate, i.e.
-- test.sql
create table foo (id int primary key, foo_id int);
alter table foo add constraint fk1 foreign key (foo_id) references foo(id);
insert into foo select 1,2;
psql -1 -vON_ERROR_STOP=on -f test.sql
and
psql -vON_ERROR_STOP=on -f test.sql
both return 3 (which is the expected behaviour on my reading of the docs).
Also, interestingly, if I wrap the first script in begin; ... commit; I
always get 3 returned.
Thanks,
Dominic.
Dominic Bevacqua
Director
BPM Logic Ltd.
http://www.bpmlogic.com
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.216
diff -c -c -r1.216 command.c
*** src/bin/psql/command.c 26 Feb 2010 02:01:17 - 1.216
--- src/bin/psql/command.c 7 Mar 2010 17:40:47 -
***
*** 1731,1740
--- 1731,1752
pset.inputfile = filename;
if (single_txn)
+ {
res = PSQLexec(BEGIN, false);
+ if (!res)
+ return EXIT_FAILURE;
+ PQclear(res);
+ }
+
result = MainLoop(fd);
+
if (single_txn)
+ {
res = PSQLexec(COMMIT, false);
+ if (!res)
+ return EXIT_FAILURE;
+ PQclear(res);
+ }
fclose(fd);
pset.inputfile = oldfilename;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql with GSS can crash
Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100: 2010/3/1 Zdenek Kotala zdenek.kot...@sun.com: Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100: On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote: Hi all, I got following stack: fd7ffed14b70 strlen () + 40 fd7ffed71665 snprintf () + e5 fd7fff36d088 pg_GSS_startup () + 88 fd7fff36d43a pg_fe_sendauth () + 15a fd7fff36e557 PQconnectPoll () + 3b7 fd7fff36e152 connectDBComplete () + a2 fd7fff36dc32 PQsetdbLogin () + 1b2 0041e96d main () + 30d 0041302c () It seems that connection is not fully configured and krbsrvname or pghost is not filled. Following code in fe-auth.c pg_GSS_startup() causes a crash: 440 maxlen = NI_MAXHOST + strlen(conn-krbsrvname) + 2; 441 temp_gbuf.value = (char *) malloc(maxlen); 442 snprintf(temp_gbuf.value, maxlen, %...@%s, 443 conn-krbsrvname, conn-pghost); 444 temp_gbuf.length = strlen(temp_gbuf.value); And following code in fe-connect.c fillPGconn() fill NULL value. 571 tmp = conninfo_getval(connOptions, krbsrvname); 572 conn-krbsrvname = tmp ? strdup(tmp) : NULL; I think that pg_GSS_startup should sanity the input. How did you get NULL in there? :-) There's a default set for that one that's PG_KRB_SRVNAM, so it really should never come out as NULL, I think... Yeah, you are right. conn-krbsrvname is postgres and conn-pghost is null Ah, good. We should defentd against that then. As for pghost, that certainly seems to be a bug. We check that one in krb5 and SSPI, but for some reason we seem to be missing it in GSSAPI. Yes. The check should be in GSSAPI too. However what I see in pg_hba.conf is following line: local all all gss Gss is used on local unix socket which probably cause a problem that conn-pghost is not filled when psql tries to connect. So there are really two errors - because we should disallow that. See attached patch - can you confirm it removes the crash with just the client side applied, and then that it properly rejects GSS with the server side applied as well? I tested it, but I cannot reproduce crash because I cannot setup illegal combination now ;-). I think it is OK. Thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: incorrect exit code from psql with single transaction + violation of deferred FK constraint
Bruce Momjian br...@momjian.us writes: The attached patch checks for the proper return from BEGIN/COMMIT, and properly frees the libpq structures. In testing, this does return 3 as you expected. Really? It looks to me like you'd get exit(1). Maybe that's the right thing, but MainLoop itself seems to return EXIT_USER not EXIT_FAILURE when it gets an error. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: incorrect exit code from psql with single transaction + violation of deferred FK constraint
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The attached patch checks for the proper return from BEGIN/COMMIT, and
properly frees the libpq structures. In testing, this does return 3 as
you expected.
Really? It looks to me like you'd get exit(1). Maybe that's the right
thing, but MainLoop itself seems to return EXIT_USER not EXIT_FAILURE
when it gets an error.
Sorry, you are right. I must have mis-read my tests. Updated patch
attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.216
diff -c -c -r1.216 command.c
*** src/bin/psql/command.c 26 Feb 2010 02:01:17 - 1.216
--- src/bin/psql/command.c 8 Mar 2010 00:29:26 -
***
*** 1731,1740
--- 1731,1752
pset.inputfile = filename;
if (single_txn)
+ {
res = PSQLexec(BEGIN, false);
+ if (!res)
+ return EXIT_USER;
+ PQclear(res);
+ }
+
result = MainLoop(fd);
+
if (single_txn)
+ {
res = PSQLexec(COMMIT, false);
+ if (!res)
+ return EXIT_USER;
+ PQclear(res);
+ }
fclose(fd);
pset.inputfile = oldfilename;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: incorrect exit code from psql with single transaction + violation of deferred FK constraint
BBruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The attached patch checks for the proper return from BEGIN/COMMIT, and
properly frees the libpq structures. In testing, this does return 3 as
you expected.
Really? It looks to me like you'd get exit(1). Maybe that's the right
thing, but MainLoop itself seems to return EXIT_USER not EXIT_FAILURE
when it gets an error.
Sorry, you are right. I must have mis-read my tests. Updated patch
attached.
I thought some more about it and realized I had to check for the
on-error-exit flag too. Updated patch attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.216
diff -c -c -r1.216 command.c
*** src/bin/psql/command.c 26 Feb 2010 02:01:17 - 1.216
--- src/bin/psql/command.c 8 Mar 2010 00:46:10 -
***
*** 1731,1740
pset.inputfile = filename;
if (single_txn)
! res = PSQLexec(BEGIN, false);
result = MainLoop(fd);
if (single_txn)
! res = PSQLexec(COMMIT, false);
fclose(fd);
pset.inputfile = oldfilename;
--- 1731,1758
pset.inputfile = filename;
if (single_txn)
! {
! if ((res = PSQLexec(BEGIN, false)) == NULL)
! {
! if (pset.on_error_stop)
! return EXIT_USER;
! }
! else
! PQclear(res);
! }
!
result = MainLoop(fd);
+
if (single_txn)
! {
! if ((res = PSQLexec(COMMIT, false)) == NULL)
! {
! if (pset.on_error_stop)
! return EXIT_USER;
! }
! else
! PQclear(res);
! }
fclose(fd);
pset.inputfile = oldfilename;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ecpg compiler warning about char* comparison
There is a complier warning in ecpg/ecpglib/error.c on HEAD: error.c: In function 'eecpg_raise_backend': error.c:309: warning: comparison with string literal results in unspecified behavior It comes from the following coparison: --- #define ECPG_SQLSTATE_ECPG_INTERNAL_ERROR YE000 char *sqlstate; if (sqlstate == ECPG_SQLSTATE_ECPG_INTERNAL_ERROR) --- Instead, should we use if (strcmp(...) == 0) here? Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] arithmetic about inet
I got some point from others.I already red and debug network.c . Now I now the basic logic behind that. But still I'm confused by arithmetic. I find some comments on that , I need some one's help. /* * int * bitncmp(l, r, n) * compare bit masks l and r, for n bits. * return: * -1, 1, or 0 in the libc tradition. * note: * network byte order assumed. this means 192.5.5.240/28 has * 0x in its fourth octet. * author: * Paul Vixie (ISC), June 1996 */ Why we finish it in this way. Can you help me?
Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
Kevin Flanagan kevi...@linkprior.com wrote: 1. you have to define the symbol BUILDING_DLL in your code before including postgres.h No, BUILDING_DLL does not work. We use PGDLLIMPORT both exported global variables and PG_MODULE_MAGIC/PG_FUNCTION_INFO_V1 for now, but actually we should always use __declspec (dllexport) for the latter cases. They are exported from *user dlls*, not the postgres' one. I'd like to propose to define PGALWAYSEXPORT macro: #ifdef WIN32 #define PGALWAYSEXPORT __declspec (dllexport) #endif and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it instead of PGDLLEXPORT. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] arithmetic about inet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Mar 08, 2010 at 09:47:00AM +0800, fanng yuan wrote: I got some point from others.I already red and debug network.c . Now I now the basic logic behind that. But still I'm confused by arithmetic. I find some comments on that , I need some one's help. /* * int * bitncmp(l, r, n) * compare bit masks l and r, for n bits. * return: * -1, 1, or 0 in the libc tradition. * note: * network byte order assumed. this means 192.5.5.240/28 has * 0x in its fourth octet. * author: * Paul Vixie (ISC), June 1996 */ Why we finish it in this way. Can you help me? Sorry, I don't understand your question. Are you asking: why this return value? If that is your question then: Paul Vixie is referring to the function strcmp() from libc: it returns an integer less than 0 if the first string is less than the second, 0 if both are equal and an integer greater than 0 if the second string is greater than the first. This is a very handy convention, which you can see at work in Kerninghan Ritchie's classical Programming in C. Now I hope I understood your question right :-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLlJYbBcgs9XrR2kYRAgebAJ9f9VtjwfYjBUtKvxG4iFQCqisnzACfdBe2 y+giKF0WENVEXgbhCPtYs2Q= =uLJS -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes: I'd like to propose to define PGALWAYSEXPORT macro: #ifdef WIN32 #define PGALWAYSEXPORT __declspec (dllexport) #endif and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it instead of PGDLLEXPORT. This seems like change for the sake of change. The existing mechanism works (as demonstrated by the fact that the contrib modules work on Windows). I don't think we should invent a new mechanism that won't be backwards-compatible. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
Tom Lane t...@sss.pgh.pa.us wrote: Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes: I'd like to propose to define PGALWAYSEXPORT macro: #ifdef WIN32 #define PGALWAYSEXPORT __declspec (dllexport) #endif and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it instead of PGDLLEXPORT. This seems like change for the sake of change. The existing mechanism works (as demonstrated by the fact that the contrib modules work on Windows). I wonder why the contrib modules can be compiled correctly because: 1. PG_MODULE_MAGIC requires dllexport. 2. Other exported variables from postgres requires dllimport. 3. Exported functions from the contrib DLLs require dllexport, but they don't have any PGDLLEXPORT tags in their functions. Did we use non-standard tools except msvc in the build frameword for core code? And what should I do for an external project? Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
On Mar 7, 2010, at 9:22 AM, Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: 2010/3/6 Tom Lane t...@sss.pgh.pa.us: The analogy I was thinking about was psql -X, but I agree that it's not obvious why this shouldn't be thought of as an additional -f file. Uh, I don't follow. When we use -f, we'll run the script and then exit. The whole point is to run it and *not* exit, since you are normally using it to set up the environment in psql. If we were going to support multiple -f options, it would be sensible to interpret -f - as read from stdin until EOF. Then you could interleave prepared scripts and stdin, which could be pretty handy. The default behavior would be equivalent to a single instance of -f -, and what you are looking for would be -X -f substitute-psqlrc -f -. Here's an initial stab at supporting multiple -f's (not counting the interpretation of -f - as STDIN). There are also a few pieces that are up for interpretation, such as the propagation of the return value of the MainLoop(). Also, while this patch supports the single- transaction mode, it does so in a way that will break if one of the scripts include explicit BEGIN/COMMIT statements (although it is no different than the existing code in this regard). Regards, David -- David Christensen End Point Corporation da...@endpoint.com psql_process_multiple_files.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
