On 2010-05-05, Tom Lane wrote:
> The problem is there's no real support inside psql for "throwing an
> error" --- we have to unwind all the state manually. In particular,
> what this problem requires is backing out the stack of flex buffers
> representing pending variable expansions. So I think
bry...@giraffe-data.com (Bryan Henderson) writes:
> The interface header files for Postgres server extensions define "bool",
> but that name is commonly used by other parts of user code, including
> by standards (C99, C++). That causes, at best, compile failures.
> If Postgres has to define a boo
bry...@giraffe-data.com (Bryan Henderson) writes:
> (a file that gets included in a user's server extension
> compilation) contains the line
> # if _MSC_VER > 1400
> In the compiler is not Microsoft C at all, _MSC_VER is undefined, and in some
> environments, the reference to it is an error (e.g
"KOIZUMI Satoru" writes:
> There are two PGTYPES_NUM_OVERFLOWs at 33.8.6. errno values of pgtypeslib.
> The latter PGTYPES_NUM_OVERFLOW would be PGTYPES_NUM_UNDERFLOW according to
> its description.
Fixed in HEAD. Thanks for the report!
regards, tom lane
--
Sent via pg
On sön, 2010-05-09 at 11:35 -0400, Tom Lane wrote:
> bry...@giraffe-data.com (Bryan Henderson) writes:
> > The interface header files for Postgres server extensions define "bool",
> > but that name is commonly used by other parts of user code, including
> > by standards (C99, C++). That causes, at
Peter Eisentraut writes:
> On sön, 2010-05-09 at 11:35 -0400, Tom Lane wrote:
>> ... we consider building server extensions with C++ to be
>> unsupported anyway.
> Um, our code has
> #ifndef __cplusplus
> #ifndef bool
> typedef char bool;
> #endif
> etc.
Yeah, I know those #if's are there, b
On Sun, May 9, 2010 at 5:58 PM, Tom Lane wrote:
> Yeah, I know those #if's are there, but whether they actually do
> anything useful is highly questionable. There is no reason to assume
> that a compiler's built-in version of bool will be bit-compatible with
> ours. And changing the width of boo
Greg Stark writes:
> On Sun, May 9, 2010 at 5:58 PM, Tom Lane wrote:
>> Yeah, I know those #if's are there, but whether they actually do
>> anything useful is highly questionable. There is no reason to assume
>> that a compiler's built-in version of bool will be bit-compatible with
>> ours. And
>As for -Wundef, it seems rather impractical to turn that on anyway given
>that it produces numerous other warnings --- a quick check in HEAD shows
It looks like my point was missed. I'm talking about compiling user code that
interfaces with Postgres. I'm specifically talking about server extens
>Um, our code has
>
>#ifndef __cplusplus
>
>#ifndef bool
>typedef char bool;
>#endif
>
>#ifndef true
>#define true((bool) 1)
>#endif
>
>etc.
>
>so somehow it was once thought that it is worth supporting other
>definitions of bool.
And the Postgres manual says you can use C++ (34.9 - C-Language
On Sun, May 9, 2010 at 6:04 PM, Tom Lane wrote:
> Huh? We build just fine on C99 compilers, AFAIK. Or are you saying
> that we should try to adopt 's definition of bool? The
> problem there is, again, that we don't know what width that will be.
No, I'm saying we should use something like pgboo
goutham jalakam wrote:
> Our application has to take backup aroung 200GB or more data based on
> Database.
>
> Physical files in the local system will be uploaded to NAS raid server based
> on Database records.
> for each and every database record associated files wil be available.
> So, more t
Erwin Brandstetter wrote:
> Function bodies are checked using the _current_ search_path instead of
> the search_path supplied by the "SET search_path" clause.
>
> Proposed solution: Function bodies should be checked with the
> search_path provided by "SET search_path" an _not_ with the current
13 matches
Mail list logo
