Thread

  1. test/example does not support win32.

    z-saito <z-saito@guitar.ocn.ne.jp> — 2009-12-30T04:49:51Z

    Hi.
    
    test/example does not support win32.
    Although I posted also in the past, I am slightly persistent.
    I think whether it also needs correction of a document. 
    
    == CVS-HEAD on as for MinGW + gcc ==
    
    testlibpq2.c: In function `main':
    testlibpq2.c:98: error: `fd_set' undeclared (first use in this function)
    testlibpq2.c:98: error: (Each undeclared identifier is reported only once
    testlibpq2.c:98: error: for each function it appears in.)
    testlibpq2.c:98: error: syntax error before "input_mask"
    testlibpq2.c:105: warning: implicit declaration of function `FD_ZERO'
    testlibpq2.c:105: error: `input_mask' undeclared (first use in this function)
    testlibpq2.c:106: warning: implicit declaration of function `FD_SET'
    testlibpq2.c:108: warning: implicit declaration of function `select'
    make: *** [testlibpq2] Error 1
    
    testlibpq3.c: In function `show_binary_results':
    testlibpq3.c:82: error: `uint32_t' undeclared (first use in this function)
    testlibpq3.c:82: error: (Each undeclared identifier is reported only once
    testlibpq3.c:82: error: for each function it appears in.)
    testlibpq3.c:82: error: syntax error before ')' token
    testlibpq3.c: In function `main':
    testlibpq3.c:115: error: `uint32_t' undeclared (first use in this function)
    testlibpq3.c:115: error: syntax error before "binaryIntVal"
    testlibpq3.c:183: error: `binaryIntVal' undeclared (first use in this function)
    testlibpq3.c:183: error: syntax error before numeric constant
    make: *** [testlibpq3] Error 1
    
    Please take into consideration. 
    
    Regards,
    Hiroshi Saito
  2. Re: test/example does not support win32.

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-12-30T04:57:50Z

    "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    > test/example does not support win32.
    
    The proposed added #includes seem quite inappropriate.  postgres_fe.h
    is meant for PG-project code, it is not supposed to have to be included
    by all end-user code.
    
    			regards, tom lane
    
    
  3. Re: test/example does not support win32.

    z-saito <z-saito@guitar.ocn.ne.jp> — 2009-12-30T05:07:37Z

    Hi Tom-san.
    
    Um, How do you consider sample which cannot build? 
    
    Regards,
    Hiroshi Saito
    
    ----- Original Message ----- 
    From: "Tom Lane" <tgl@sss.pgh.pa.us>
    
    
    > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    >> test/example does not support win32.
    > 
    > The proposed added #includes seem quite inappropriate.  postgres_fe.h
    > is meant for PG-project code, it is not supposed to have to be included
    > by all end-user code.
    > 
    > 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
    
    
  4. Re: test/example does not support win32.

    Alvaro Herrera <alvherre@commandprompt.com> — 2009-12-30T14:56:29Z

    Hiroshi Saito wrote:
    > Hi Tom-san.
    > 
    > Um, How do you consider sample which cannot build?
    
    I think testlibpq2.c is missing a couple of system includes, sys/types.h
    and unistd.h (or alternatively select.h); and testlibpq3.c is missing
    stdint.h.  Or so say my (POSIX) manpages anyway.
    
    -- 
    Alvaro Herrera                                http://www.CommandPrompt.com/
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
    
    
  5. Re: test/example does not support win32.

    z-saito <z-saito@guitar.ocn.ne.jp> — 2009-12-30T15:19:02Z

    Hi Alvaro-san.
    
    Yes, I thinks that it is an exact idea. However, this example was not helped. 
    fd_set complains.... 
    Thanks!
    
    It seems that pg_bench takes the thing same again into consideration. 
    Anyway,  If it is called example of end-user code, what is the evasion method
    of fd_set? 
    
    Regards,
    Hiroshi Saito
    
    ----- Original Message ----- 
    From: "Alvaro Herrera" <alvherre@commandprompt.com>
    
    
    > Hiroshi Saito wrote:
    >> Hi Tom-san.
    >> 
    >> Um, How do you consider sample which cannot build?
    > 
    > I think testlibpq2.c is missing a couple of system includes, sys/types.h
    > and unistd.h (or alternatively select.h); and testlibpq3.c is missing
    > stdint.h.  Or so say my (POSIX) manpages anyway.
    > 
    > -- 
    > Alvaro Herrera                                http://www.CommandPrompt.com/
    > PostgreSQL Replication, Consulting, Custom Development, 24x7 support
    > 
    > -- 
    > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
    > To make changes to your subscription:
    > http://www.postgresql.org/mailpref/pgsql-hackers
    
    
  6. Re: test/example does not support win32.

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-12-30T15:33:59Z

    "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    > Yes, I thinks that it is an exact idea. However, this example was not helped. 
    > fd_set complains.... 
    > Thanks!
    
    > It seems that pg_bench takes the thing same again into consideration. 
    > Anyway,  If it is called example of end-user code, what is the evasion method
    > of fd_set? 
    
    On reflection I think it's just wrong to expect that the examples will
    compile out-of-the-box on every platform.  The only way that that can
    possibly happen is if they depend on our configuration infrastructure,
    which is exactly what I feel they should not depend on.  Any client
    program that has ambitions of portability is going to have its own
    autoconf stuff, so injecting ours into a piece of sample code is just
    going to result in headaches.  Even including only pg_config.h would
    be a serious invasion of application namespace.
    
    Looking at pgbench, or any other one of our client-side programs,
    is not relevant to the point here.  Those programs *are* supposed
    to rely on the PG autoconf environment.
    
    We can certainly add some more standard #includes to the examples
    if they're obviously missing some.  But that isn't going to get us
    to a point where they'll compile everywhere without change.
    
    			regards, tom lane
    
    
  7. Re: test/example does not support win32.

    Bruce Momjian <bruce@momjian.us> — 2009-12-30T15:38:12Z

    Tom Lane wrote:
    > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    > > Yes, I thinks that it is an exact idea. However, this example was not helped. 
    > > fd_set complains.... 
    > > Thanks!
    > 
    > > It seems that pg_bench takes the thing same again into consideration. 
    > > Anyway,  If it is called example of end-user code, what is the evasion method
    > > of fd_set? 
    > 
    > On reflection I think it's just wrong to expect that the examples will
    > compile out-of-the-box on every platform.  The only way that that can
    > possibly happen is if they depend on our configuration infrastructure,
    > which is exactly what I feel they should not depend on.  Any client
    > program that has ambitions of portability is going to have its own
    > autoconf stuff, so injecting ours into a piece of sample code is just
    > going to result in headaches.  Even including only pg_config.h would
    > be a serious invasion of application namespace.
    > 
    > Looking at pgbench, or any other one of our client-side programs,
    > is not relevant to the point here.  Those programs *are* supposed
    > to rely on the PG autoconf environment.
    > 
    > We can certainly add some more standard #includes to the examples
    > if they're obviously missing some.  But that isn't going to get us
    > to a point where they'll compile everywhere without change.
    
    Well, those example programs are pretty clean libpq apps so I don't see
    why they should using platform-specific stuff.
    
    -- 
      Bruce Momjian  <bruce@momjian.us>        http://momjian.us
      EnterpriseDB                             http://enterprisedb.com
    
      + If your life is a hard drive, Christ can be your backup. +
    
    
  8. Re: test/example does not support win32.

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-12-30T15:44:49Z

    Bruce Momjian <bruce@momjian.us> writes:
    > Well, those example programs are pretty clean libpq apps so I don't see
    > why they should using platform-specific stuff.
    
    Example #2 depends on select(), which depends on fd_set, so you're
    already into territory where there are issues.
    
    			regards, tom lane
    
    
  9. Re: test/example does not support win32.

    Andrew Dunstan <andrew@dunslane.net> — 2009-12-30T15:45:36Z

    
    Tom Lane wrote:
    > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    >   
    >> Yes, I thinks that it is an exact idea. However, this example was not helped. 
    >> fd_set complains.... 
    >> Thanks!
    >>     
    >
    >   
    >> It seems that pg_bench takes the thing same again into consideration. 
    >> Anyway,  If it is called example of end-user code, what is the evasion method
    >> of fd_set? 
    >>     
    >
    > On reflection I think it's just wrong to expect that the examples will
    > compile out-of-the-box on every platform.  The only way that that can
    > possibly happen is if they depend on our configuration infrastructure,
    > which is exactly what I feel they should not depend on.  Any client
    > program that has ambitions of portability is going to have its own
    > autoconf stuff, so injecting ours into a piece of sample code is just
    > going to result in headaches.  Even including only pg_config.h would
    > be a serious invasion of application namespace.
    >
    > Looking at pgbench, or any other one of our client-side programs,
    > is not relevant to the point here.  Those programs *are* supposed
    > to rely on the PG autoconf environment.
    >
    > We can certainly add some more standard #includes to the examples
    > if they're obviously missing some.  But that isn't going to get us
    > to a point where they'll compile everywhere without change.
    >
    > 			
    >   
    
    That would be all good and well if we didn't already rely on the 
    configure setup. But we do - the Makefile includes src/Makefile.global, 
    which is built by configure.
    
    Anyway, let's see how far we can get with including some standard header 
    files.
    
    cheers
    
    andrew
    
    
  10. Re: test/example does not support win32.

    z-saito <z-saito@guitar.ocn.ne.jp> — 2009-12-30T15:57:09Z

    Hi Andrew-san.
    
    Although this is a standard in windows.
    
    *** testlibpq2.c.orig   Wed Dec 30 13:19:03 2009
    --- testlibpq2.c        Thu Dec 31 00:52:52 2009
    ***************
    *** 24,34 ****
    --- 24,39 ----
       *
       *     INSERT INTO TBL1 VALUES (10);
       */
    +
    + #ifdef WIN32
    + #include <windows.h>
    + #endif
      #include <stdio.h>
      #include <stdlib.h>
      #include <string.h>
      #include <errno.h>
      #include <sys/time.h>
    + #include <sys/types.h>
      #include "libpq-fe.h"
    
      static void
    
    Does this become the standard which you consider?
    or #IFDEF Isn't it allowed?
    
    Regards,
    Hiroshi Saito
    
    ----- Original Message ----- 
    From: "Andrew Dunstan" <andrew@dunslane.net>
    To: "Tom Lane" <tgl@sss.pgh.pa.us>
    Cc: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>; "Alvaro Herrera" 
    <alvherre@commandprompt.com>; "pgsql-hackers" <pgsql-hackers@postgresql.org>; "Bruce 
    Momjian" <bruce@momjian.us>
    Sent: Thursday, December 31, 2009 12:45 AM
    Subject: Re: [HACKERS] test/example does not support win32.
    
    
    >
    >
    > Tom Lane wrote:
    >> "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    >>
    >>> Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set 
    >>> complains.... Thanks!
    >>>
    >>
    >>
    >>> It seems that pg_bench takes the thing same again into consideration. Anyway,  If it is 
    >>> called example of end-user code, what is the evasion method
    >>> of fd_set?
    >>
    >> On reflection I think it's just wrong to expect that the examples will
    >> compile out-of-the-box on every platform.  The only way that that can
    >> possibly happen is if they depend on our configuration infrastructure,
    >> which is exactly what I feel they should not depend on.  Any client
    >> program that has ambitions of portability is going to have its own
    >> autoconf stuff, so injecting ours into a piece of sample code is just
    >> going to result in headaches.  Even including only pg_config.h would
    >> be a serious invasion of application namespace.
    >>
    >> Looking at pgbench, or any other one of our client-side programs,
    >> is not relevant to the point here.  Those programs *are* supposed
    >> to rely on the PG autoconf environment.
    >>
    >> We can certainly add some more standard #includes to the examples
    >> if they're obviously missing some.  But that isn't going to get us
    >> to a point where they'll compile everywhere without change.
    >>
    >>
    >>
    >
    > That would be all good and well if we didn't already rely on the configure setup. But we 
    > do - the Makefile includes src/Makefile.global, which is built by configure.
    >
    > Anyway, let's see how far we can get with including some standard header files.
    >
    > cheers
    >
    > andrew 
    
    
    
  11. Re: test/example does not support win32.

    Andrew Dunstan <andrew@dunslane.net> — 2009-12-30T16:05:36Z

    
    Hiroshi Saito wrote:
    > Hi Andrew-san.
    >
    > Although this is a standard in windows.
    >
    > *** testlibpq2.c.orig   Wed Dec 30 13:19:03 2009
    > --- testlibpq2.c        Thu Dec 31 00:52:52 2009
    > ***************
    > *** 24,34 ****
    > --- 24,39 ----
    >   *
    >   *     INSERT INTO TBL1 VALUES (10);
    >   */
    > +
    > + #ifdef WIN32
    > + #include <windows.h>
    > + #endif
    >  #include <stdio.h>
    >  #include <stdlib.h>
    >  #include <string.h>
    >  #include <errno.h>
    >  #include <sys/time.h>
    > + #include <sys/types.h>
    >  #include "libpq-fe.h"
    >
    >  static void
    >
    > Does this become the standard which you consider?
    > or #IFDEF Isn't it allowed?
    >
    >
    I certainly think we can use ifdefs. This addition seems OK to me at 
    first glance. Does it solve the problem you encountered?
    
    cheers
    
    andrew
    
    
  12. Re: test/example does not support win32.

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-12-30T16:09:30Z

    Andrew Dunstan <andrew@dunslane.net> writes:
    > Tom Lane wrote:
    >> On reflection I think it's just wrong to expect that the examples will
    >> compile out-of-the-box on every platform.
    
    > That would be all good and well if we didn't already rely on the 
    > configure setup. But we do - the Makefile includes src/Makefile.global, 
    > which is built by configure.
    
    That makefile is not part of the examples.  It wouldn't get copied and
    pasted into someone's source code.
    
    > Anyway, let's see how far we can get with including some standard header 
    > files.
    
    Sure, no objection to that.  It's when somebody starts wanting to use
    HAVE_FOO symbols that I get unhappy.
    
    			regards, tom lane
    
    
  13. Re: test/example does not support win32.

    z-saito <z-saito@guitar.ocn.ne.jp> — 2009-12-30T16:21:31Z

    Hi Andrew-san.
    
    This saves a windows users.
    I appreciate your suggestion.
    Thanks!
    
    P.S)
    I often use by the test by nmake at the time of independent creation of libpq. 
    
    Regards,
    Hiroshi Saito
    
    ----- Original Message ----- 
    From: "Andrew Dunstan" <andrew@dunslane.net>
    
    
    > 
    > 
    > Hiroshi Saito wrote:
    >> Hi Andrew-san.
    >>
    >> Although this is a standard in windows.
    >>
    >> *** testlibpq2.c.orig   Wed Dec 30 13:19:03 2009
    >> --- testlibpq2.c        Thu Dec 31 00:52:52 2009
    >> ***************
    >> *** 24,34 ****
    >> --- 24,39 ----
    >>   *
    >>   *     INSERT INTO TBL1 VALUES (10);
    >>   */
    >> +
    >> + #ifdef WIN32
    >> + #include <windows.h>
    >> + #endif
    >>  #include <stdio.h>
    >>  #include <stdlib.h>
    >>  #include <string.h>
    >>  #include <errno.h>
    >>  #include <sys/time.h>
    >> + #include <sys/types.h>
    >>  #include "libpq-fe.h"
    >>
    >>  static void
    >>
    >> Does this become the standard which you consider?
    >> or #IFDEF Isn't it allowed?
    >>
    >>
    > I certainly think we can use ifdefs. This addition seems OK to me at 
    > first glance. Does it solve the problem you encountered?
    > 
    > cheers
    > 
    > andrew
  14. Re: test/example does not support win32.

    Magnus Hagander <magnus@hagander.net> — 2009-12-30T16:24:42Z

    2009/12/30 Hiroshi Saito <z-saito@guitar.ocn.ne.jp>:
    > Hi Andrew-san.
    >
    > This saves a windows users.
    > I appreciate your suggestion.
    > Thanks!
    
    This one looks much better. +1 for this version :-)
    
    -- 
     Magnus Hagander
     Me: http://www.hagander.net/
     Work: http://www.redpill-linpro.com/
    
    
  15. Re: test/example does not support win32.

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-12-30T16:33:44Z

    "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    > [ examples_win32_patch2 ]
    
    Is the addition of -DFRONTEND actually needed, and if so why?
    We shouldn't be depending on that in any user-exposed code, I would
    think.  Otherwise I don't have any objection to this version.
    
    			regards, tom lane
    
    
  16. Re: test/example does not support win32.

    z-saito <z-saito@guitar.ocn.ne.jp> — 2009-12-30T16:47:52Z

    Hi Tom-san.
    
    Ahh.. It was correction of the test of often...
    again, the pursued relation was seen, I think that it is good now.
    Thanks!!
    
    Regards,
    Hiroshi Saito
    
    ----- Original Message ----- 
    From: "Tom Lane" <tgl@sss.pgh.pa.us>
    
    
    > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
    >> [ examples_win32_patch2 ]
    > 
    > Is the addition of -DFRONTEND actually needed, and if so why?
    > We shouldn't be depending on that in any user-exposed code, I would
    > think.  Otherwise I don't have any objection to this version.
    > 
    > 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