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
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 se
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 chang
-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 o
"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 (dll
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
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
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).
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
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 retu
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
> >
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_
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 det
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 th
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 thi
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
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. Th
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 a
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 on
19 matches
Mail list logo
