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)

Thu, 7 Aug 2003 14:43:10 +0200 (MET DST)
ohp@pyrenet.fr
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

Thu, 07 Aug 2003 10:46:47 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.4beta1 build problem on unixware 


--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


Thu, 07 Aug 2003 09:58:00 -0500
Larry Rosenman <ler@lerctr.org>
Re: 7.4beta1 build problem on unixware 
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


Thu, 7 Aug 2003 23:12:05 +0800 (WST)
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
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

Thu, 07 Aug 2003 11:17:39 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: new psql \d command 
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)

Thu, 7 Aug 2003 17:20:58 +0200 (MET DST)
ohp@pyrenet.fr
Re: 7.4beta1 build problem on unixware 
Tom Lane wrote:
> 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.

I thought the pretty-printing stuff was designed specifically for psql
\d and third-party apps like pgadmin.

Let's face it, the non-pretty-printing output is "pretty" ugly, and
pretty-printing will improve that.

-- 
  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

Thu, 7 Aug 2003 11:23:00 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: new psql \d command
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, Pennsylvania 19073

Thu, 7 Aug 2003 11:28:35 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: new psql \d command
Bruce Momjian wrote:

>Tom Lane wrote:
>  
>
>>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.
>>    
>>
>
>I thought the pretty-printing stuff was designed specifically for psql
>\d and third-party apps like pgadmin.
>
Yes it was, but it can be meaningful for pg_dump too.
The pretty-print stuff will inflate the dump with many spaces which 
doesn't make any sense with formats not meant to be read by humans, 
(--format=c), but --format=p output might well be used for user editing. 
So IMHO an option to enable pretty-dump can be useful.

Regards,
Andreas


Thu, 07 Aug 2003 17:53:11 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: new psql \d command
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



Thu, 07 Aug 2003 18:00:48 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: new psql \d command
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, Pennsylvania 19073

Thu, 7 Aug 2003 12:08:19 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: new psql \d command
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

Thu, 07 Aug 2003 12:22:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: new psql \d command 
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, Pennsylvania 19073

Thu, 7 Aug 2003 12:29:57 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: new psql \d command
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



Thu, 07 Aug 2003 18:31:19 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: new psql \d command
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



Thu, 07 Aug 2003 18:38:43 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: new psql \d command

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
>
>  
>


Thu, 07 Aug 2003 12:41:21 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: new psql \d command
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

Thu, 07 Aug 2003 16:15:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: new psql \d command 
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


Thu, 07 Aug 2003 23:24:29 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: new psql \d command
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 with time 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 with time 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_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 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_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 IS
 NOT NULL AND shop_orders.refund_datetime IS NOT NULL
UNION ALL
 SELECT 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 ALL
 SELECT 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 ALL
 SELECT 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
>


Fri, 8 Aug 2003 09:17:05 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: new psql \d command 
> 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


Fri, 8 Aug 2003 09:20:42 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: new psql \d command
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"

Fri, 8 Aug 2003 14:01:04 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: new psql \d command
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)
Fri, 8 Aug 2003 17:05:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: new psql \d command
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


Sat, 9 Aug 2003 17:45:55 +0200
Kurt Roeckx <Q@ping.be>
Re: 7.4beta1 build problem on unixware
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

Sat, 09 Aug 2003 11:48:31 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.4beta1 build problem on unixware 
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


Sat, 9 Aug 2003 18:27:44 +0200
Kurt Roeckx <Q@ping.be>
Re: 7.4beta1 build problem on unixware
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

Sat, 09 Aug 2003 12:31:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.4beta1 build problem on unixware 


--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


Sat, 09 Aug 2003 15:15:05 -0500
Larry Rosenman <ler@lerctr.org>
Re: 7.4beta1 build problem on unixware 


--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


Sat, 09 Aug 2003 15:26:40 -0500
Larry Rosenman <ler@lerctr.org>
Re: 7.4beta1 build problem on unixware 
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)

Sun, 10 Aug 2003 00:25:07 +0200 (MET DST)
ohp@pyrenet.fr
Re: 7.4beta1 build problem on unixware
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

Sat, 09 Aug 2003 18:57:10 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.4beta1 build problem on unixware 


--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;      /* protofamily for 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


Sat, 09 Aug 2003 18:45:15 -0500
Larry Rosenman <ler@lerctr.org>
Re: 7.4beta1 build problem on unixware 

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, Pennsylvania 19073

Mon, 11 Aug 2003 18:39:41 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: new psql \d command

could be \dn for describe namespace for ei : \dn pg_catalog,
or only \dn to list all namespaces

?

Tue, 12 Aug 2003 10:47:34 +0200 (CEST)
ivan <iv@psycho.pl>
Re: new psql \d command
> could be \dn for describe namespace for ei : \dn pg_catalog,
> or only \dn to list all namespaces

Already done in CVS...

Chris


Tue, 12 Aug 2003 17:03:24 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: new psql \d command
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

Thu, 14 Aug 2003 15:15:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.4beta1 build problem on unixware 