Thread: 7.4beta1 build problem on unixware
Hi, I've just tried the cvs on uw 7.13. It fails on compiling hba.c: UX:acomp: ERROR: "hba.c", line 651: undefined symbol: AI_NUMERICHOST UX:acomp: ERROR: "hba.c", line 1237: undefined symbol: AI_NUMERICHOST gmake[3]: *** [hba.o] Error 1 gmake[2]: *** [libpq-recursive] Error 2 gmake[1]: *** [all] Error 2 gmake: *** [all] Error 2 UX:make: ERROR: fatal error. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery)
ohp@pyrenet.fr writes:
> I've just tried the cvs on uw 7.13. It fails on compiling hba.c:
> UX:acomp: ERROR: "hba.c", line 651: undefined symbol: AI_NUMERICHOST
> UX:acomp: ERROR: "hba.c", line 1237: undefined symbol: AI_NUMERICHOST
This seems similar to Weiping He's problem on AIX. As I said to him:
Looking at src/include/getaddrinfo.h, it seems we assume we need to
supply definitions of AI_NUMERICHOST and NI_NUMERICHOST if and only
if not HAVE_STRUCT_ADDRINFO. That's probably a bogus assumption.
Can you tell us what configure found for HAVE_STRUCT_ADDRINFO and
HAVE_GETADDRINFO? Also, which of the macros defined in that file
exist in your system headers?
regards, tom lane
--On Thursday, August 07, 2003 10:46:47 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > ohp@pyrenet.fr writes: >> I've just tried the cvs on uw 7.13. It fails on compiling hba.c: >> UX:acomp: ERROR: "hba.c", line 651: undefined symbol: AI_NUMERICHOST >> UX:acomp: ERROR: "hba.c", line 1237: undefined symbol: AI_NUMERICHOST > > This seems similar to Weiping He's problem on AIX. As I said to him: > > Looking at src/include/getaddrinfo.h, it seems we assume we need to > supply definitions of AI_NUMERICHOST and NI_NUMERICHOST if and only > if not HAVE_STRUCT_ADDRINFO. That's probably a bogus assumption. > Can you tell us what configure found for HAVE_STRUCT_ADDRINFO and > HAVE_GETADDRINFO? Also, which of the macros defined in that file > exist in your system headers? We (UnixWare) have getaddrinfo(), but it's probably to an older standard. We don't really have a IPv6 stack, just the API for it. Tom: Would an account on my box help? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Hi guys (tom), Just reminding people that there was a question regarding my changes to psql's \d command. I'm not sure if everyone wanted all the identifier names double quoted or not... And are people happy with the layout in general? Also, I think it'd be nice if my recent patch to use the new pg_get_viewdef was applied for release (I think it's merely a bug fix). It might be a bit risky getting pg_dump to use it though? Chris
Hi Tom, I have NI_NUMERICHOST defined in netdb.h I too can provide an account on my machine(s) if you need a few On Thu, 7 Aug 2003, Tom Lane wrote: > Date: Thu, 07 Aug 2003 10:46:47 -0400 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list <pgsql-hackers@postgresql.org> > Subject: Re: [HACKERS] 7.4beta1 build problem on unixware > > ohp@pyrenet.fr writes: > > I've just tried the cvs on uw 7.13. It fails on compiling hba.c: > > UX:acomp: ERROR: "hba.c", line 651: undefined symbol: AI_NUMERICHOST > > UX:acomp: ERROR: "hba.c", line 1237: undefined symbol: AI_NUMERICHOST > > This seems similar to Weiping He's problem on AIX. As I said to him: > > Looking at src/include/getaddrinfo.h, it seems we assume we need to > supply definitions of AI_NUMERICHOST and NI_NUMERICHOST if and only > if not HAVE_STRUCT_ADDRINFO. That's probably a bogus assumption. > Can you tell us what configure found for HAVE_STRUCT_ADDRINFO and > HAVE_GETADDRINFO? Also, which of the macros defined in that file > exist in your system headers? > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery)
Christopher Kings-Lynne wrote: > Hi guys (tom), > > Just reminding people that there was a question regarding my changes to > psql's \d command. I'm not sure if everyone wanted all the identifier > names double quoted or not... I assume we don't want them always quoted. > And are people happy with the layout in general? Also, I think it'd be > nice if my recent patch to use the new pg_get_viewdef was applied for > release (I think it's merely a bug fix). It is in the queue to be applied. > It might be a bit risky getting pg_dump to use it though? I don't think we every want pg_dump to use it --- better accurate than pretty in there. There seems to be some tough assumptions that have to be made in that function that are better used for visual-only cases. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: >It might be a bit risky getting pg_dump to use it though? > > > >I don't think we every want pg_dump to use it --- better accurate than >pretty in there. > Agreed. > There seems to be some tough assumptions that have to >be made in that function that are better used for visual-only cases. > > Still, if there's something not precise, it should be cleared. Which tough assumptions are made that seem doubtful to you? Regards, Andreas
Andreas Pflug wrote: > Bruce Momjian wrote: > > >It might be a bit risky getting pg_dump to use it though? > > > > > > > >I don't think we every want pg_dump to use it --- better accurate than > >pretty in there. > > > Agreed. > > > There seems to be some tough assumptions that have to > >be made in that function that are better used for visual-only cases. > > > > > Still, if there's something not precise, it should be cleared. Which > tough assumptions are made that seem doubtful to you? It just seemed complex to figure out which operators needed parens and which didn't. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> It just seemed complex to figure out which operators needed parens and
> which didn't.
The fact that the first attempt was wrong doesn't improve my faith in
that code one bit ;-). I don't want pg_dump invoking it, even as an
option. Someone will get burnt.
regards, tom lane
Bruce Momjian wrote: >>> >>> >>Still, if there's something not precise, it should be cleared. Which >>tough assumptions are made that seem doubtful to you? >> >> > >It just seemed complex to figure out which operators needed parens and >which didn't. > > Only very-well-documented operators (Chapter 4.1.6) are parens-optimized (+-*/%); this topic was reviewed from Tom. When using ^ or user defined other operators, they will be decorated with (maybe useless) parens. Regards, Andreas
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > It just seemed complex to figure out which operators needed parens and > > which didn't. > > The fact that the first attempt was wrong doesn't improve my faith in > that code one bit ;-). I don't want pg_dump invoking it, even as an > option. Someone will get burnt. Yes, even if we get it right now, it might break in the future by a change somewhere else, and we may not discover the breakage until it is too late. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: >Tom Lane wrote: > > >>Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >> >>>It just seemed complex to figure out which operators needed parens and >>>which didn't. >>> >>> >>The fact that the first attempt was wrong doesn't improve my faith in >>that code one bit ;-). >> It was posted expressively with request for comment/review to locate bogus/non-fail-safe assumptions. That operator thing was introduced last-minute before feature freeze, coded late at night. >>I don't want pg_dump invoking it, even as an option. Someone will get burnt. >> >> > >Yes, even if we get it right now, it might break in the future by a >change somewhere else, and we may not discover the breakage until it is >too late. > Doesn't this apply to any change? pg_dump can be used as a kind of reverse-engineer tool, that's why user-readability can make sense. I wonder when somebody wishes pgAdmin3 to do that for a complete db (effectively duplicating pg_dump's feature)... Regards, Andreas
An alternative might be something that postprocesses the output from pg_dump into, say, XML. I've been thinking about that. I might put it on my todo list. andrew Tom Lane wrote: >Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >>It just seemed complex to figure out which operators needed parens and >>which didn't. >> >> > >The fact that the first attempt was wrong doesn't improve my faith in >that code one bit ;-). I don't want pg_dump invoking it, even as an >option. Someone will get burnt. > > regards, tom lane > > >
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Only very-well-documented operators (Chapter 4.1.6) are parens-optimized
> (+-*/%);
At the moment ... but you can be sure there will be demand to get
smarter.
regards, tom lane
Tom Lane wrote: >Andreas Pflug <pgadmin@pse-consulting.de> writes: > > >>Only very-well-documented operators (Chapter 4.1.6) are parens-optimized >>(+-*/%); >> >> > >At the moment ... but you can be sure there will be demand to get smarter. > > I never claimed to implement the ultimate solution, just wanted to hit 95 %, and the current solution probably covers even more. IMHO it's a good balance between result and complexity, which always makes things susceptible for bugs. Regards, Andreas
Well for me it's the difference between this:
australia=# \d affiliates_transactions View "public.affiliates_transactions" Column | Type
| Modifiers
--------------+--------------------------+-----------affiliate_id | integer |date | timestamp
withtime zone |type | text |type_id | integer |amount | numeric
|
View definition: ((((((((((((SELECT palm_buyers.affiliate_id,
timestamptz(abstime(palm_buyers.datetime)) AS date, 'Palm' AS "type", 1 AS
type_id, palm_buyers.affiliate_amount AS amount FROM palm_buyers WHERE
((palm_buyers.affiliate_id IS NOT NULL) AND (palm_buyers.affiliate_amount IS
NOT NULL))) UNION ALL (SELECT palm_buyers.affiliate_id,
timestamptz(abstime(palm_buyers.refund_datetime)) AS date, 'Palm Refund' AS
"type", 2 AS type_id, (- palm_buyers.affiliate_amount) AS amount FROM
palm_buyers WHERE (((palm_buyers.affiliate_id IS NOT NULL) AND
(palm_buyers.affiliate_amount IS NOT NULL)) AND (palm_buyers.refund_datetime
IS NOT NULL))))) UNION ALL (SELECT shop_orders.affiliate_id,
timestamptz((shop_orders.datetime)::abstime) AS date, 'Books' AS "type", 3
AS type_id, shop_orders.affiliate_amount AS amount FROM shop_orders WHERE
((shop_orders.affiliate_id IS NOT NULL) AND (shop_orders.affiliate_amount IS
NOT NULL))))) UNION ALL (SELECT shop_orders.affiliate_id,
timestamptz(abstime(shop_orders.refund_datetime)) AS date, 'Books Refund' AS
"type", 4 AS type_id, (- shop_orders.affiliate_amount) AS amount FROM
shop_orders WHERE (((shop_orders.affiliate_id IS NOT NULL) AND
(shop_orders.affiliate_amount IS NOT NULL)) AND (shop_orders.refund_datetime
IS NOT NULL))))) UNION ALL (SELECT transactions_log.affiliate_id,
timestamptz(transactions_log.date) AS date, 'Site' AS "type", 5 AS type_id,
transactions_log.affiliate_amount AS amount FROM transactions_log WHERE
((transactions_log.affiliate_id IS NOT NULL) AND
(transactions_log.affiliate_amount IS NOT NULL))))) UNION ALL (SELECT
transactions_log.affiliate_id,
timestamptz(abstime(transactions_log.refund_datetime)) AS date, 'Site
Refund' AS "type", 6 AS type_id, (- transactions_log.affiliate_amount) AS
amount FROM transactions_log WHERE (((transactions_log.affiliate_id IS NOT
NULL) AND (transactions_log.affiliate_amount IS NOT NULL)) AND
(transactions_log.refund_datetime IS NOT NULL))))) UNION ALL (SELECT
affiliates_payments.affiliate_id, affiliates_payments.datetime AS date,
'Affiliate Payment' AS "type", 7 AS type_id, (- affiliates_payments.amount)
AS amount FROM affiliates_payments));
and this:
australia=# \d affiliates_transactions View "public.affiliates_transactions" Column | Type
| Modifiers
--------------+--------------------------+-----------affiliate_id | integer |date | timestamp
withtime zone |type | text |type_id | integer |amount | numeric
|
View definition:SELECT palm_buyers.affiliate_id, timestamptz(abstime(palm_buyers.datetime))
AS
date, 'Palm' AS "type", 1 AS type_id, palm_buyers.affiliate_amount AS amount FROM palm_buyers WHERE
palm_buyers.affiliate_idIS NOT NULL AND
palm_buyers.affiliate_amount ISNOT NULL
UNION ALLSELECT palm_buyers.affiliate_id,
timestamptz(abstime(palm_buyers.refund_datetim
e)) AS date, 'Palm Refund' AS "type", 2 AS type_id, -
palm_buyers.affiliate_amou
nt AS amount FROM palm_buyers WHERE palm_buyers.affiliate_id IS NOT NULL AND
palm_buyers.affiliate_amount ISNOT NULL AND palm_buyers.refund_datetime IS NOT NULL
UNION ALLSELECT shop_orders.affiliate_id, timestamptz(shop_orders.datetime::abstime)
AS
date, 'Books' AS "type", 3 AS type_id, shop_orders.affiliate_amount AS
amount FROM shop_orders WHERE shop_orders.affiliate_id IS NOT NULL AND
shop_orders.affiliate_amount ISNOT NULL
UNION ALLSELECT shop_orders.affiliate_id,
timestamptz(abstime(shop_orders.refund_datetim
e)) AS date, 'Books Refund' AS "type", 4 AS type_id, -
shop_orders.affiliate_amo
unt AS amount FROM shop_orders WHERE shop_orders.affiliate_id IS NOT NULL AND
shop_orders.affiliate_amount ISNOT NULL AND shop_orders.refund_datetime IS NOT NULL
UNION ALLSELECT transactions_log.affiliate_id, timestamptz(transactions_log.date) AS
dat
e, 'Site' AS "type", 5 AS type_id, transactions_log.affiliate_amount AS
amount FROM transactions_log WHERE transactions_log.affiliate_id IS NOT NULL AND
transactions_log.affiliate
_amount IS NOT NULL
UNION ALLSELECT transactions_log.affiliate_id,
timestamptz(abstime(transactions_log.refu
nd_datetime)) AS date, 'Site Refund' AS "type", 6 AS type_id, -
transactions_log
.affiliate_amount AS amount FROM transactions_log WHERE transactions_log.affiliate_id IS NOT NULL AND
transactions_log.affiliate
_amount IS NOT NULL AND transactions_log.refund_datetime IS NOT NULL
UNION ALLSELECT affiliates_payments.affiliate_id, affiliates_payments.datetime AS
date,
'Affiliate Payment' AS "type", 7 AS type_id, - affiliates_payments.amount AS
amo
unt FROM affiliates_payments;
The second is a lot more readable :)
Chris
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Cc: "pgsql-hackers list" <pgsql-hackers@postgresql.org>
Sent: Thursday, August 07, 2003 11:17 PM
Subject: Re: new psql \d command
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> > It might be a bit risky getting pg_dump to use it though?
>
> I definitely don't want pg_dump using the pretty-print stuff ;-).
> I'm neutral on whether to use it in psql's \d commands.
>
> regards, tom lane
>
> I assume we don't want them always quoted. Problem with that is that someone has to move the to-quote-or-not function from pg_dump into psql... Chris
On Fri, Aug 08, 2003 at 09:17:05AM +0800, Christopher Kings-Lynne wrote: > australia=# \d affiliates_transactions > View "public.affiliates_transactions" [...] > View definition: > SELECT palm_buyers.affiliate_id, timestamptz(abstime(palm_buyers.datetime)) > AS > date, 'Palm' AS "type", 1 AS type_id, palm_buyers.affiliate_amount AS amount > FROM palm_buyers > WHERE palm_buyers.affiliate_id IS NOT NULL AND > palm_buyers.affiliate_amount IS > NOT NULL > UNION ALL > SELECT palm_buyers.affiliate_id, > timestamptz(abstime(palm_buyers.refund_datetim > e)) AS date, 'Palm Refund' AS "type", 2 AS type_id, - > palm_buyers.affiliate_amou > nt AS amount Is this the real output or you were bitten by cut&paste wrapping? It doesn't look good to me as is... [several other cases in the rest of the definition] -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "The ability to monopolize a planet is insignificant next to the power of the source"
Christopher Kings-Lynne wrote: > > I assume we don't want them always quoted. > > Problem with that is that someone has to move the to-quote-or-not function > from pg_dump into psql... Attached is a psql/Makefile patch that makes fmtId() available to psql C code. I tried a test and it seemed to work. Keep in mind the return value of fmtId() has to be used before fmtId() is called again, so places that pass two parameters to printf will need to call fmtId(), save the result, then call it again and pass them both to printf. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/bin/psql/Makefile =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/psql/Makefile,v retrieving revision 1.37 diff -c -c -r1.37 Makefile *** src/bin/psql/Makefile 8 Aug 2003 04:52:21 -0000 1.37 --- src/bin/psql/Makefile 8 Aug 2003 20:48:41 -0000 *************** *** 15,25 **** REFDOCDIR= $(top_srcdir)/doc/src/sgml/ref ! override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) -DFRONTEND OBJS= command.o common.o help.o input.o stringutils.o mainloop.o copy.o \ startup.o prompt.o variables.o large_obj.o print.o describe.o \ ! tab-complete.o mbprint.o all: submake-libpq submake-libpgport psql --- 15,26 ---- REFDOCDIR= $(top_srcdir)/doc/src/sgml/ref ! override CPPFLAGS := -I$(top_srcdir)/src/bin/pg_dump -I$(libpq_srcdir) $(CPPFLAGS) -DFRONTEND OBJS= command.o common.o help.o input.o stringutils.o mainloop.o copy.o \ startup.o prompt.o variables.o large_obj.o print.o describe.o \ ! tab-complete.o mbprint.o \ ! dumputils.o $(top_builddir)/src/backend/parser/keywords.o all: submake-libpq submake-libpgport psql *************** *** 27,32 **** --- 28,36 ---- $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@ help.o: $(srcdir)/sql_help.h + + dumputils.c: % : $(top_srcdir)/src/bin/pg_dump/% + rm -f $@ && $(LN_S) $< . ifdef PERL $(srcdir)/sql_help.h: create_help.pl $(wildcard $(REFDOCDIR)/*.sgml)
Kurt Roeckx <Q@ping.be> writes:
> On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp@pyrenet.fr wrote:
>> I have NI_NUMERICHOST defined in netdb.h
> That's for getnameinfo(). getnameinfo() is older than
> getaddrinfo() ...
> If you have that, I assume you have AI_NUMERICHOST in the same
> file too ... ?
Nope, they don't :-(. I committed fixes a day or two ago that seem to
take care of this, though we won't know for sure till it's tried on more
platforms ...
regards, tom lane
On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp@pyrenet.fr wrote: > Hi Tom, > > I have NI_NUMERICHOST defined in netdb.h That's for getnameinfo(). getnameinfo() is older than getaddrinfo() ... If you have that, I assume you have AI_NUMERICHOST in the same file too ... ? Kurt
On Sat, Aug 09, 2003 at 11:48:31AM -0400, Tom Lane wrote: > Kurt Roeckx <Q@ping.be> writes: > > On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp@pyrenet.fr wrote: > >> I have NI_NUMERICHOST defined in netdb.h > > > If you have that, I assume you have AI_NUMERICHOST in the same > > file too ... ? > > Nope, they don't :-(. I committed fixes a day or two ago that seem to > take care of this, though we won't know for sure till it's tried on more > platforms ... If they don't have it defined, it's not going to do what we expect and we might be better of using our replacement functions. Kurt
Kurt Roeckx <Q@ping.be> writes:
> If they don't have it defined, it's not going to do what we
> expect and we might be better of using our replacement functions.
We will if we don't find struct addrinfo. See notes at top of getaddrinfo.h.
regards, tom lane
--On Saturday, August 09, 2003 12:31:14 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Kurt Roeckx <Q@ping.be> writes: >> If they don't have it defined, it's not going to do what we >> expect and we might be better of using our replacement functions. > > We will if we don't find struct addrinfo. See notes at top of > getaddrinfo.h. > > regards, tom lane and it BREAKS on UnixWare. I can connect on unix domain sockets, but NOT on an IP socket. I'm futzing with #undef'ing HAVE_GETADDRINFO for a test. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
--On Saturday, August 09, 2003 15:15:05 -0500 Larry Rosenman <ler@lerctr.org> wrote: > > > --On Saturday, August 09, 2003 12:31:14 -0400 Tom Lane > <tgl@sss.pgh.pa.us> wrote: > >> Kurt Roeckx <Q@ping.be> writes: >>> If they don't have it defined, it's not going to do what we >>> expect and we might be better of using our replacement functions. >> >> We will if we don't find struct addrinfo. See notes at top of >> getaddrinfo.h. >> >> regards, tom lane > and it BREAKS on UnixWare. I can connect on unix domain sockets, but NOT > on an IP socket. > > I'm futzing with #undef'ing HAVE_GETADDRINFO for a test. Ok, with using OUR src/port/getaddrinfo.c (by #undef'ing HAVE_GETADDRINFO and adding getaddrinfo.o to Makefile.global's LIBOBJS, it works again. We need to devise a configure test for broken/old getaddrinfo()'s. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Sat, 9 Aug 2003, Kurt Roeckx wrote: > Date: Sat, 9 Aug 2003 17:45:55 +0200 > From: Kurt Roeckx <Q@ping.be> > To: ohp@pyrenet.fr > Cc: Tom Lane <tgl@sss.pgh.pa.us>, > pgsql-hackers list <pgsql-hackers@postgresql.org>, > Larry Rosenman <ler@lerctr.org> > Subject: Re: [HACKERS] 7.4beta1 build problem on unixware > > On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp@pyrenet.fr wrote: > > Hi Tom, > > > > I have NI_NUMERICHOST defined in netdb.h > > That's for getnameinfo(). getnameinfo() is older than > getaddrinfo() ... > > If you have that, I assume you have AI_NUMERICHOST in the same > file too ... ? > No > > Kurt > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery)
Larry Rosenman <ler@lerctr.org> writes:
> Ok, with using OUR src/port/getaddrinfo.c (by #undef'ing HAVE_GETADDRINFO
> and adding getaddrinfo.o to Makefile.global's LIBOBJS, it works again.
> We need to devise a configure test for broken/old getaddrinfo()'s.
That seems Turing-complete in general :-(.
It may well be that the problem is not so much that your getaddrinfo
doesn't work, as that we're not interfacing to it correctly. Which of
the macros in src/include/getaddrinfo.h are actually being absorbed from
the system headers, and which are we using our own values for?
regards, tom lane
--On Saturday, August 09, 2003 18:57:10 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
> Larry Rosenman <ler@lerctr.org> writes:
>> Ok, with using OUR src/port/getaddrinfo.c (by #undef'ing
>> HAVE_GETADDRINFO and adding getaddrinfo.o to Makefile.global's LIBOBJS,
>> it works again.
>
>> We need to devise a configure test for broken/old getaddrinfo()'s.
>
> That seems Turing-complete in general :-(.
>
> It may well be that the problem is not so much that your getaddrinfo
> doesn't work, as that we're not interfacing to it correctly. Which of
> the macros in src/include/getaddrinfo.h are actually being absorbed from
> the system headers, and which are we using our own values for?
Good question.
Here's excerpts from UnixWare's /usr/include/netdb.h:
/** Flag values for getaddrinfo()*/
#define AI_PASSIVE 0x01 /* socket address is intended for bind() */
#define AI_CANONNAME 0x02 /* request for canonical name */
/** Error values for getaddrinfo()*/
#define EAI_BADFLAGS 1 /* invalid value for ai_flags */
#define EAI_NONAME 2 /* neither name nor service provided/found
*/
#define EAI_AGAIN 3 /* temporary failure in name resolution */
#define EAI_FAIL 4 /* non-recoverable failure in name resoln */
#define EAI_NODATA 5 /* no address associated with name */
#define EAI_FAMILY 6 /* ai_family not supported */
#define EAI_SOCKTYPE 7 /* ai_socktype not supported */
#define EAI_SERVICE 8 /* service not supported for ai_socktype */
#define EAI_ADDRFAMILY 9 /* address family for name not supported */
#define EAI_MEMORY 10 /* memory allocation failure */
#define EAI_SYSTEM 11 /* system error */
/** Structure used by getaddrinfo()*/
struct addrinfo { int ai_flags; /* input flags */ int ai_family; /*
protofamilyfor socket */ int ai_socktype; /* socket type */ int ai_protocol;
/*protocol for socket */ int ai_addrlen; /* length of socket address */ struct sockaddr
*ai_addr; /* socket address */ char *ai_canonname; /* canonical name for service locn
*/ struct addrinfo *ai_next; /* pointer to next in list */
};
a copy of the manpage is at:
http://www.lerctr.org:8458/en/man/html.3N/getaddrinfo.3N.html
I'm at a loss from here....
LER
>
> regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Added to TODO: * Prevent unneeded quoting in psql \d output using fmtId() --------------------------------------------------------------------------- Christopher Kings-Lynne wrote: > > I assume we don't want them always quoted. > > Problem with that is that someone has to move the to-quote-or-not function > from pg_dump into psql... > > Chris > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> could be \dn for describe namespace for ei : \dn pg_catalog, > or only \dn to list all namespaces Already done in CVS... Chris
could be \dn for describe namespace for ei : \dn pg_catalog, or only \dn to list all namespaces ?
Larry Rosenman <ler@lerctr.org> writes:
>> and it BREAKS on UnixWare. I can connect on unix domain sockets, but NOT
>> on an IP socket.
>>
>> I'm futzing with #undef'ing HAVE_GETADDRINFO for a test.
> Ok, with using OUR src/port/getaddrinfo.c (by #undef'ing HAVE_GETADDRINFO
> and
> adding getaddrinfo.o to Makefile.global's LIBOBJS, it works again.
I thought we might be a bit optimistic in assuming we could #define all
those macros as whatever we wanted ...
It seems getaddrinfo() exists but has no AI_NUMERICHOST flag bit on
Larry's machine ... and it actively rejects unrecognized ai_flags
settings. The AI_NUMERICHOST flag bit seems to be inessential, so
I've just #define'd it as zero if we are using the system getaddrinfo
and we can't find a definition in <netdb.h>.
regards, tom lane