Tom Lane wrote:
>> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
>> in this case, which makes #include fail.
>> Does anyone have an idea how to best fix this problem in the
>> source tree? I'm willing to implement and test.
>
> I've committed changes for this in CVS, plea
"Albe Laurenz" writes:
> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
> in this case, which makes #include fail.
> Does anyone have an idea how to best fix this problem in the
> source tree? I'm willing to implement and test.
I've committed changes for this in CVS, plea
Alvaro Herrera writes:
> Tom Lane wrote:
>> In most of the other cases the #include is done in an associated .y
>> file, but there is none in psql. Anyone have a thought which of
>> psql's .c files would be the most appropriate host?
> mainloop.c?
Yeah, that's about the same conclusion I had co
Tom Lane wrote:
> In most of the other cases the #include is done in an associated .y
> file, but there is none in psql. Anyone have a thought which of
> psql's .c files would be the most appropriate host?
mainloop.c?
--
Alvaro Herrerahttp://www.CommandPrompt.co
"Albe Laurenz" writes:
>> Why the "OBJECT_MODE" exported to 32 is not sufficient ?
> I dug around a little, and the problem is in psqlscan.c which is generated
> from psqlscan.l by flex.
> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
> in this case, which makes #include
