Can anyone please tell me where in the source code, I can find the
compelte query.
--
Regards
Imad
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > >> My feeling is that the *.txt is actually misleading because
> > >people will
> > >> think of it as a file full of freeform text (paragraphs) and not a
> > >> configuration file.
> > >
> > >Why would they think that? If notepad tends to auto-wra
Bruce Momjian wrote:
> [.][..] 1138945.s 1138945.w
> abook.mab bookmarks-1.html bookmarks-2.html
> bookmarks-3.html
> bookmarks-4.html bookmarks-5.html bookmarks-6.html bookmarks.html
> [Cache][Cache.Tras
Magnus Hagander wrote:
> >> My feeling is that the *.txt is actually misleading because
> >people will
> >> think of it as a file full of freeform text (paragraphs) and not a
> >> configuration file.
> >
> >Why would they think that? If notepad tends to auto-wrap files then
> >this argument has s
Current plans are to wrap the PG 8.0 final tarball Monday evening, with
public announcement Wednesday morning ("morning" and "evening" measured
in North American east coast time zones). The slightly longer than
usual delay is to let the Windows installer team put up a final Windows
installer packa
Magnus Hagander wrote:
#ifdef WIN32
#include "win32.h"
#ifndef _WIN32_IE
#define _WIN32_IE 0x0400
I beleive his will break if _WIN32_IE is previously defined as something
<0x0400. Not sure if we build with a patform SDK with that old defaults
at all, but just to be sure it's probably better t
>>>The error appears to be on line that uses NEAR and complains
>about it
>>>... I see that the MinGW windef.h defines NEAR as empty, while
>>>the MSVC
>>>windef.h defines it as "near". Don't know if that makes a difference.
>>>
>>>
>>
>>Some reading up on MSDN gives this:
>>http://msdn.mic
>Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>Creating library .\Release\libpqdll.lib and object
>.\Release\libpqdll.exp
>> libpq.lib(fe-connect.obj) : error LNK2019: unresolved
>external symbol
>> [EMAIL PROTECTED] referenced in function
>_pqGetHomeDirectory
>> .\Release\libpq.dll : fatal
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp
> libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol
> [EMAIL PROTECTED] referenced in function _pqGetHomeDirectory
> .\Release\libpq.dll : fatal error LNK11
Magnus Hagander wrote:
The error appears to be on line that uses NEAR and complains about it
... I see that the MinGW windef.h defines NEAR as empty, while
the MSVC
windef.h defines it as "near". Don't know if that makes a difference.
Some reading up on MSDN gives this:
http://msdn.microso
>>>The trouble seems to come from these 2 lines:
>>>
>>>+ #define _WIN32_IE 0x0400
>>>+ #include
>>>
>>>First, on MSVC, _WIN32_IE is already defined at that point.
>If you get
>>>around that then processing the include file causes errors.
>>>
>>>
>>
>>Interesting - mingw was supposed to use
Magnus Hagander wrote:
Recent changes to interfaces/libpg/fe-connect.c have broken
MSVC builds,
which I am reliably informed are definitely still required - at least
some uses of libpq.dll made with gcc apparently cause the resulting
builds or applications to blow up.
Can you get some mor
Chris Mair <[EMAIL PROTECTED]> writes:
> It seems strtod() is to blame.
> ...
> on the PlayStation 2 returns:
> input string is 'Infinity'
> strtod returned val = inf
> errno = 0
> endptr points to 'inity'
> Would it be worth treating this case apart in float.c, or should we just
On Sun, 2005-01-09 at 17:45, Peter Eisentraut wrote:
> Well, it does not readily explain that 'infinity' is rejected as invalid
> input syntax. You should get an overflow or some large value, at
> least.
>
> The relevant code is in src/backend/utils/adt/float.c.
You're right.
I had a look at
Tom Lane wrote:
> Perhaps also the filename should be "-jp" not "-ja"? I agree with
> the complainant that the former is more standard.
ja = Japanese (ISO 639 language code)
jp = Japan (ISO 3166 country code)
Since the installation pack is probably targeted at users speaking
Japanese, much like
Oleg Bartunov wrote:
> I just completed russian translation of .po files ( except
> ru.po for backend ).
> diff against rc3 is available from
> http://www.sai.msu.su/~megera/postgres/docs/ru.po-8.0.0.rc3.diff.gz
This patch doesn't apply cleanly. Please send the individual PO files.
--
Peter Eis
Chris Mair wrote:
> The Playstation 2 hardware manuals confirm that the FPU has
> no support for NaN and +/-Inf. That explains the regression diffs.
> (EE Core User's Manual Version 5, p. 153)
Well, it does not readily explain that 'infinity' is rejected as invalid
input syntax. You should get a
On Fri, Jan 07, 2005 at 11:06:58PM -0600, Jaime Casanova wrote:
Jaime,
> i was looking at the unsuported features in the RC4
> docs and found this:
>
> F671| Enhanced integrity management| Subqueries in CHECK| intentionally
> omitted
>
> Why is it *intentionally omitted*?
> Is it to hard? or
>Recent changes to interfaces/libpg/fe-connect.c have broken
>MSVC builds,
>which I am reliably informed are definitely still required - at least
>some uses of libpq.dll made with gcc apparently cause the resulting
>builds or applications to blow up.
Can you get some more specifics on that? We
On Tue, 4 Jan 2005, Peter Eisentraut wrote:
> With the 8.0 release around the corner, this is as good a time as ever
> to send in the last translation updates. If your files are not in CVS
> right now, I don't have them, so please send them again in this case.
How much time do we have?
Unfortunat
20 matches
Mail list logo