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

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

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

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)

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

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

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

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

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

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

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

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

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