Re: [HACKERS] Explicit psqlrc

2010-03-07 Thread David Christensen


On Mar 7, 2010, at 9:22 AM, Tom Lane wrote:


Magnus Hagander  writes:

2010/3/6 Tom Lane :

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


Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?

2010-03-07 Thread Takahiro Itagaki

Tom Lane  wrote:

> Takahiro Itagaki  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] Visual Studio 2005, C-language function - avoiding hacks?

2010-03-07 Thread Tom Lane
Takahiro Itagaki  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] arithmetic about inet

2010-03-07 Thread tomas
-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?

2010-03-07 Thread Takahiro Itagaki

"Kevin Flanagan"  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


[HACKERS] arithmetic about inet

2010-03-07 Thread fanng yuan
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?


[HACKERS] ecpg compiler warning about char* comparison

2010-03-07 Thread Takahiro Itagaki
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


Re: [HACKERS] Re: incorrect exit code from psql with single transaction + violation of deferred FK constraint

2010-03-07 Thread Bruce Momjian
BBruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian  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  http://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


Re: [HACKERS] Re: incorrect exit code from psql with single transaction + violation of deferred FK constraint

2010-03-07 Thread Bruce Momjian
Tom Lane wrote:
> Bruce Momjian  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  http://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

2010-03-07 Thread Tom Lane
Bruce Momjian  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] psql with GSS can crash

2010-03-07 Thread Zdenek Kotala
Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100:
> 2010/3/1 Zdenek Kotala :
> > Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
> >> On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala  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


[HACKERS] Re: incorrect exit code from psql with single transaction + violation of deferred FK constraint

2010-03-07 Thread Bruce Momjian

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  http://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] Core dump running PL/Perl installcheck with bleadperl [PATCH]

2010-03-07 Thread Tom Lane
Tim Bunce  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


Re: [HACKERS] Explicit psqlrc

2010-03-07 Thread Bruce Momjian
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  http://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] Explicit psqlrc

2010-03-07 Thread Magnus Hagander
2010/3/7 Tom Lane :
> Magnus Hagander  writes:
>> 2010/3/7 Tom Lane :
>>> 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

2010-03-07 Thread Tom Lane
Magnus Hagander  writes:
> 2010/3/7 Tom Lane :
>> 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-03-07 Thread Magnus Hagander
2010/3/7 Tom Lane :
> Magnus Hagander  writes:
>> 2010/3/6 Tom Lane :
>>> 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

2010-03-07 Thread Tom Lane
Magnus Hagander  writes:
> 2010/3/6 Tom Lane :
>> 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-03-07 Thread Magnus Hagander
2010/3/6 Tom Lane :
> Peter Eisentraut  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