Re: new psql \d command

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(at)pyrenet(dot)fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

ohp(at)pyrenet(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> ohp(at)pyrenet(dot)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(at)lerctr(dot)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

Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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

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(at)sss(dot)pgh(dot)pa(dot)us>
> To: ohp(at)pyrenet(dot)fr
> Cc: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
> Subject: Re: [HACKERS] 7.4beta1 build problem on unixware
>
> ohp(at)pyrenet(dot)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(at)pyrenet(dot)fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

Tom Lane wrote:
> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>Tom Lane wrote:
>
>
>>Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

Bruce Momjian wrote:

>Tom Lane wrote:
>
>
>>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)pse-consulting(dot)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(at)pse-consulting(dot)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 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(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org>
Sent: Thursday, August 07, 2003 11:17 PM
Subject: Re: new psql \d command

> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp(at)pyrenet(dot)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

Kurt Roeckx <Q(at)ping(dot)be> writes:
> On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp(at)pyrenet(dot)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 Sat, Aug 09, 2003 at 11:48:31AM -0400, Tom Lane wrote:
> Kurt Roeckx <Q(at)ping(dot)be> writes:
> > On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp(at)pyrenet(dot)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(at)ping(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> Kurt Roeckx <Q(at)ping(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

--On Saturday, August 09, 2003 15:15:05 -0500 Larry Rosenman
<ler(at)lerctr(dot)org> wrote:

>
>
> --On Saturday, August 09, 2003 12:31:14 -0400 Tom Lane
> <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Kurt Roeckx <Q(at)ping(dot)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(at)lerctr(dot)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(at)ping(dot)be>
> To: ohp(at)pyrenet(dot)fr
> Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,
> pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>,
> Larry Rosenman <ler(at)lerctr(dot)org>
> Subject: Re: [HACKERS] 7.4beta1 build problem on unixware
>
> On Thu, Aug 07, 2003 at 05:20:58PM +0200, ohp(at)pyrenet(dot)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(at)pyrenet(dot)fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

Larry Rosenman <ler(at)lerctr(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> Larry Rosenman <ler(at)lerctr(dot)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(at)lerctr(dot)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(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

?

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

Already done in CVS...

Chris

Larry Rosenman <ler(at)lerctr(dot)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