[HACKERS] Reverse Engineering - search constraints are not explicitly stated in the tables from the VIEW

2014-11-12 Thread nill
I am analyzing query plans generated by the view in the database PostgreSQL
8.3, looking for missing information constraints not explicitly registrants
in the tables.
In nested queries, (ex. IN clause, ...), the query plan consist in the
evaluation of the subplane derived from clause (SELECT * ) and external
queries.
In the present case:
HashAggregate  (cost=15.14..15.16 rows=1 width=247)
 -  Nested Loop IN Join  (cost=3.46..15.12 rows=1 width=247)
   Join Filter: (o.c_doctype_id = c_doctype.c_doctype_id)
 -  Hash Left Join  (cost=3.46..12.38 rows=1 width=247)
   Hash Cond: (bp.c_invoiceschedule_id = si.c_invoiceschedule_id)
   Filter: ((o.invoicerule = 'I'::bpchar) OR ((o.invoicerule =
'O'::bpchar) AND (NOT (subplan))) OR ((o.invoicerule = 'D'::bpchar) AND
(l.qtyinvoiced  l.qtydelivered)) OR ((o.invoicerule = 'S'::bpchar) AND
(bp.c_invoiceschedule_id IS NULL)) OR ((o.invoicerule = 'S'::bpchar) AND
(bp.c_invoiceschedule_id IS NOT NULL) AND ((si.invoicefrequency IS NULL) OR
(si.invoicefrequency = 'D'::bpchar) OR (si.invoicefrequency = 'W'::bpchar)
OR ((si.invoicefrequency = 'T'::bpchar) AND
(((adempiere.trunc((o.dateordered)::timestamp with time zone) =
(((adempiere.firstof(adempiere.getdate(), 'MM'::character
varying))::timestamp with time zone OPERATOR(adempiere.+)
si.invoicedaycutoff) - 1)) AND (adempiere.trunc(adempiere.getdate()) =
(((adempiere.firstof((o.dateordered)::timestamp with time zone,
'MM'::character varying))::timestamp with time zone OPERATOR(adempiere.+)
si.invoiceday) - 1))) OR ((adempiere.trunc((o.dateordered)::timestamp with
time zone) = (((adempiere.firstof(adempiere.getdate(), 'MM'::character
varying))::timestamp with time zone OPERATOR(adempiere.+)
si.invoicedaycutoff) + 14)) AND (adempiere.trunc(adempiere.getdate()) =
(((adempiere.firstof((o.dateordered)::timestamp with time zone,
'MM'::character varying))::timestamp with time zone OPERATOR(adempiere.+)
si.invoiceday) + 14) OR ((si.invoicefrequency = 'M'::bpchar) AND
(adempiere.trunc((o.dateordered)::timestamp with time zone) =
(((adempiere.firstof(adempiere.getdate(), 'MM'::character
varying))::timestamp with time zone OPERATOR(adempiere.+)
si.invoicedaycutoff) - 1)) AND (adempiere.trunc(adempiere.getdate()) =
(((adempiere.firstof((o.dateordered)::timestamp with time zone,
'MM'::character varying))::timestamp with time zone OPERATOR(adempiere.+)
si.invoiceday) - 1))
  -  Hash Join  (cost=2.44..3.87 rows=3 width=300)
Hash Cond: (l.c_order_id = o.c_order_id)
-  Seq Scan on c_orderline l  (cost=0.00..1.31 rows=25
width=141)
  Filter: (qtyordered  qtyinvoiced)
   -  Hash  (cost=2.40..2.40 rows=3 width=172)
  -  Hash Join  (cost=1.13..2.40 rows=3 width=172)
Hash Cond: (bp.c_bpartner_id = o.c_bpartner_id)
-  Seq Scan on c_bpartner bp  (cost=0.00..1.17
rows=17 width=26)
-  Hash  (cost=1.10..1.10 rows=3 width=159)
  -  Seq Scan on c_order o 
(cost=0.00..1.10 rows=3 width=159)
Filter: (docstatus = ANY
('{CO,CL,IP}'::bpchar[]))
  -  Hash  (cost=1.01..1.01 rows=1 width=47)
-  Seq Scan on c_invoiceschedule si  (cost=0.00..1.01
rows=1 width=47)
  SubPlan
-  Seq Scan on c_orderline zz1  (cost=0.00..1.38 rows=1
width=0)
  Filter: ((qtyordered  qtydelivered) AND (c_order_id =
$0))
-  Seq Scan on c_doctype  (cost=0.00..2.73 rows=1 width=13)
  Filter: ((c_doctype.docbasetype = 'SOO'::bpchar) AND
(c_doctype.docsubtypeso  ALL ('{ON,OB,WR}'::bpchar[])))

In the analysis of the query plan and its subplane, I can not understand
what the parameter $0 represents, without looking the SQL query. My question
is: looking only at the query plan product, you can understand what is the
parameter $0?

SELECT o.ad_client_id, o.ad_org_id, o.c_bpartner_id, o.c_order_id,
o.documentno, o.dateordered, o.c_doctype_id, sum((l.qtyordered -
l.qtyinvoiced) * l.priceactual) AS totallines
FROM c_order o
JOIN c_orderline l ON o.c_order_id = l.c_order_id
JOIN c_bpartner bp ON o.c_bpartner_id = bp.c_bpartner_id
LEFT JOIN c_invoiceschedule si ON bp.c_invoiceschedule_id =
si.c_invoiceschedule_id
WHERE (o.docstatus = ANY (ARRAY['CO'::bpchar, 'CL'::bpchar, 'IP'::bpchar]))
AND 
(o.c_doctype_id IN ( SELECT c_doctype.c_doctype_id
 FROM c_doctype
   WHERE c_doctype.docbasetype = 'SOO'::bpchar AND
(c_doctype.docsubtypeso  ALL (ARRAY['ON'::bpchar, 'OB'::bpchar,
'WR'::bpchar] AND l.qtyordered  l.qtyinvoiced 
 AND (o.invoicerule = 'I'::bpchar OR o.invoicerule =
'O'::bpchar 
 AND NOT (EXISTS ( SELECT 1 FROM c_orderline zz1
   WHERE **zz1.c_order_id =
o.c_order_id** AND zz1.qtyordered  zz1.qtydelivered)
   

Re: [HACKERS] Reverse Engineering - search constraints are not explicitly stated in the tables from the VIEW

2014-11-12 Thread Tom Lane
nill nill...@hotmail.com writes:
 I am analyzing query plans generated by the view in the database PostgreSQL
 8.3, looking for missing information constraints not explicitly registrants
 in the tables.

You realize of course that 8.3 is nearly 7 years old and has been out of
support for awhile.

 In the analysis of the query plan and its subplane, I can not understand
 what the parameter $0 represents, without looking the SQL query. My question
 is: looking only at the query plan product, you can understand what is the
 parameter $0?

It's a variable passed down from the outer query level.  It's true that
you can't tell which variable, in 8.3.  Less obsolete versions produce
more readable output though.  (I won't claim it's perfect; we still don't
try very hard to decompile ANY/ALL subplans.)

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Reverse Engineering

2001-08-23 Thread Tom Lane

Hannu Krosing [EMAIL PROTECTED] writes:
 Peter Harvey wrote:
 2. How do I determine the AccessMethod specified when an index was
 created?

 you can parse it from pg_indexes.indexdef 

... which relies on pg_get_indexdef(index OID).

Or, look at pg_class.relam, which is zero for regular tables and a pg_am
OID for indexes.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Reverse Engineering

2001-08-23 Thread Hannu Krosing

Peter Harvey wrote:
 
 Great progress today on my Reverse Engineering efforts. However; I have
 some comments.
 
 1. How can I switch databases (where I would normally use USE)?

You just open another connection .

If you mean psql jou do 
\c otherdatabasename

 2. How do I determine the AccessMethod specified when an index was
 created?

you can parse it from pg_indexes.indexdef 

A great source for reverse engineering is source of pg_dump as it has 
to do all the reverse engineering in order to dump everything.

 3. It would be cool if the catalog objects had comments on them in
 pg_description. Very few do.

Yes it would :)

-
Hannu

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[HACKERS] Reverse Engineering

2001-08-23 Thread Peter Harvey

There seem to be several ways to get at just about anything in the
Catalog Tables. The ODBC driver, psql, and pg_dump typically use
slightly diff sql and you guys have suggested even better ways. Forgive
me as I ask for more.

How do I determine the foriegn keys in a table?

I see pg_class.relfkeys and pg_class.relrefs. I am not sure what the
diff is between the two. In anycase; where can I go to find the
table/column(s) for each fk?

Having this info will allow me to accurately connect the tables in the
reverse engineered ERD. Very cool.

Peter




---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[HACKERS] Reverse Engineering

2001-08-22 Thread Peter Harvey

Great progress today on my Reverse Engineering efforts. However; I have
some comments.

1. How can I switch databases (where I would normally use USE)?

2. How do I determine the AccessMethod specified when an index was
created?

3. It would be cool if the catalog objects had comments on them in
pg_description. Very few do.

Peter




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl