473,386 Members | 1,702 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,386 software developers and data experts.

Bug: 8.0 beta1 either view optimization or pgdump/pgrestore

I just did a dump and restore of my database and one of my views did
not recreate.

The error received was :
pg_restore.exe: [archiver (db)] could not execute query: ERROR: column reference "pricinggroupid" is ambiguous

I checked the function in the original database, using PGAdmin, and
the system seemed to have slightly changed my query.
Part of my query was a virtual table (i.e joining on (select *
from ...) as tablename ) and the system changed that to:
(select fielda,fieldb,fieldc from...) the problem is that there were
joined tables in that virtual table with identical fieldnames. As
the optimizer did not qualify the field names with the table names, it
makes ambiguous columns. That being said, the view does work after it
is created.

I assume this is a bug in the view optimization.

Thank You
Sim Zacks
IT Manager
CompuLab
04-829-0145 - Office
04-832-5251 - Fax
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #1
5 2311
Sim Zacks <si*@compulab.co.il> writes:
I just did a dump and restore of my database and one of my views did
not recreate. The error received was :
pg_restore.exe: [archiver (db)] could not execute query: ERROR: column reference "pricinggroupid" is ambiguous I checked the function in the original database, using PGAdmin, and
the system seemed to have slightly changed my query.
Part of my query was a virtual table (i.e joining on (select *
from ...) as tablename ) and the system changed that to:
(select fielda,fieldb,fieldc from...) the problem is that there were
joined tables in that virtual table with identical fieldnames.


The view creation should have failed to begin with, then. Could we see
the *exact* problem and not a handwavy description?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #2
OOps. Didn't send it to the list. (There has to be a better way of
doing this then always having to remember to change the recipient.)

I'm sorry, I thought I described the problem pretty clearly.
Here is the actual queries with comment annotations where the problem
occurred.

1) This is the query that I typed in:
create or replace view qry_AssembliesMissingInfo as
SELECT a.AssemblyID, a.AssemblyName, a.PackageID, a.Package, a.SupplierID, a.NumPins, case when numpins is null then '' else 'Num Pins Not Specified. ' end || case when PackagePricingGroupID is null then '' else 'Package Not in a Pricing Group. ' end || case when (PackagePricingGroupID is not null And BasePrice is null) Or PricePerPin is null then 'Group Prices are Not Configured' else '' end AS Problem
FROM qry_AssembliesMissingInfo1 a LEFT JOIN

/*Here is the virtual table I mentioned using select * on a join*/
(select * from PackagePricingGroups b Inner JOIN PricingGroups c ON b.PricingGroupID = c.PricingGroupID) groups

ON a.PackageID = groups.PackageID AND a.SupplierID = groups.SupplierID
WHERE (a.NumPins Is Null AND groups.BasePrice Is Null) OR (groups.BasePrice Is Null AND groups.PricePerPin Is Null)
OR (coalesce(PricePerPin,0)>0 and coalesce(NumPins,0)=0)
GROUP BY a.AssemblyID, a.AssemblyName, a.PackageID, a.Package, a.SupplierID, a.NumPins, case when numpins is null then '' else 'Num Pins Not Specified. ' end || case when PackagePricingGroupID is null then '' else 'Package Not in a Pricing Group. ' end || case when (PackagePricingGroupID is not null And BasePrice is null) Or PricePerPin is null then 'Group Prices are Not Configured' else '' end, groups.BasePrice, groups.PricePerPin;
2) This is what PGAdmin shows after I have created view:
-- View: "qry_assembliesmissinginfo"

-- DROP VIEW qry_assembliesmissinginfo;

CREATE OR REPLACE VIEW qry_assembliesmissinginfo AS
SELECT a.assemblyid, a.assemblyname, a.packageid, a.package, a.supplierid, a.numpins, (
CASE
WHEN numpins IS NULL THEN ''::text
ELSE 'Num Pins Not Specified. '::text
END ||
CASE
WHEN packagepricinggroupid IS NULL THEN ''::text
ELSE 'Package Not in a Pricing Group. '::text
END) ||
CASE
WHEN packagepricinggroupid IS NOT NULL AND baseprice IS NULL OR priceperpin IS NULL THEN 'Group Prices are Not Configured'::text
ELSE ''::text
END AS problem
FROM qry_assembliesmissinginfo1 a

/*Here is where the problem comes in as you can see there are a
number of fields with the same name, such as pricinggroupid,
createuserid... */

LEFT JOIN ( SELECT packagepricinggroupid, pricinggroupid, packageid, createuserid, createdate, modifyuserid, modifydate, pricinggroupid, description, supplierid, baseprice, priceperpin, currencyid, createuserid, createdate, modifyuserid, modifydate
FROM packagepricinggroups b
JOIN pricinggroups c ON b.pricinggroupid = c.pricinggroupid) groups ON a.packageid = groups.packageid AND a.supplierid = groups.supplierid
WHERE a.numpins IS NULL AND groups.baseprice IS NULL OR groups.baseprice IS NULL AND groups.priceperpin IS NULL OR COALESCE(priceperpin, 0::double precision) > 0::double precision AND COALESCE(numpins, 0) = 0
GROUP BY a.assemblyid, a.assemblyname, a.packageid, a.package, a.supplierid, a.numpins, (
CASE
WHEN numpins IS NULL THEN ''::text
ELSE 'Num Pins Not Specified. '::text
END ||
CASE
WHEN packagepricinggroupid IS NULL THEN ''::text
ELSE 'Package Not in a Pricing Group. '::text
END) ||
CASE
WHEN packagepricinggroupid IS NOT NULL AND baseprice IS NULL OR priceperpin IS NULL THEN 'Group Prices are Not Configured'::text
ELSE ''::text
END, groups.baseprice, groups.priceperpin;

3) Exactly what happened.
My view worked fine after I created it.
I did a Backup using PGAdmin (which uses pg_dump)
I did a restore to a new database using PGAdmin (which uses PG_restore)
The restore gave me the ambiguous error I mentioned before
on that view.
I took the PGAdmin version of my view and saw that it had
extrapolated the fields from * and that was causing the
ambiguity. I then changed it back to * and executed the
create or replace view statement.
The view now works again.

Thank You
Sim Zacks
IT Manager
CompuLab
04-829-0145 - Office
04-832-5251 - Fax

__________________________________________________ ______________________________

Sim Zacks <si*@compulab.co.il> writes:
I just did a dump and restore of my database and one of my views did
not recreate. The error received was :
pg_restore.exe: [archiver (db)] could not execute query: ERROR: column reference "pricinggroupid" is ambiguous I checked the function in the original database, using PGAdmin, and
the system seemed to have slightly changed my query.
Part of my query was a virtual table (i.e joining on (select *
from ...) as tablename ) and the system changed that to:
(select fielda,fieldb,fieldc from...) the problem is that there were
joined tables in that virtual table with identical fieldnames.
The view creation should have failed to begin with, then. Could we see
the *exact* problem and not a handwavy description?

regards, tom lane

Thank You
Sim Zacks
IT Manager
CompuLab
04-829-0145 - Office
04-832-5251 - Fax

__________________________________________________ ______________________________

Sim Zacks <si*@compulab.co.il> writes: I just did a dump and restore of my database and one of my views did
not recreate. The error received was :
pg_restore.exe: [archiver (db)] could not execute query: ERROR: column reference "pricinggroupid" is ambiguous I checked the function in the original database, using PGAdmin, and
the system seemed to have slightly changed my query.
Part of my query was a virtual table (i.e joining on (select *
from ...) as tablename ) and the system changed that to:
(select fielda,fieldb,fieldc from...) the problem is that there were
joined tables in that virtual table with identical fieldnames.


The view creation should have failed to begin with, then. Could we see
the *exact* problem and not a handwavy description?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #3
Sim Zacks <si*@compulab.co.il> writes:
/*Here is the virtual table I mentioned using select * on a join*/
(select * from PackagePricingGroups b Inner JOIN PricingGroups c ON b.PricingGroupID = c.PricingGroupID) groups


Okay, evidently the problem is that you have identically named
columns in the two tables PackagePricingGroups and PricingGroups,
so the "groups" join contains duplicate column names. (AFAICS this
is not illegal per the SQL spec, but I wonder whether it shouldn't
be, because it's very hard to avoid ambiguity.)

I've tweaked ruleutils.c for 8.0 so that the display looks like

....
LEFT JOIN ( SELECT b.packagepricinggroupid, b.pricinggroupid,
b.packageid, b.createuserid, b.createdate, b.modifyuserid,
b.modifydate, c.pricinggroupid, c.description,
c.supplierid, c.baseprice, c.priceperpin, c.currencyid,
c.createuserid, c.createdate, c.modifyuserid, c.modifydate
FROM packagepricinggroups b
JOIN pricinggroups c ON
....

which solves this particular issue. I'm not sure a complete solution is
possible in the presence of duplicate column names; perhaps you should
modify the query to avoid that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #4
As I was not using any of those duplicate columns, * was easier to use
and I did not think about trying to use the other ones.
In fact when you do try to use one of those columns in the query, it
doesn't allow the query because of ambiguous columns.

Thank you for fixing this particular problem, even though it doesn't
solve the global question it does allow you to seamlessly backup and
restore functions that work correctly in PG. I do not think that
anything needs to be answered in this regards, because if you wanted
to actually use any of those fields it would give you the same
ambiguity error and you would have to change the query to use aliases
for the identical field names. In any case, a query trying to use identical
field names would not work to begin with, so there is no call to fix
anything so long as it does not change existing behavior.

Thank You
Sim Zacks
IT Manager
CompuLab
04-829-0145 - Office
04-832-5251 - Fax

__________________________________________________ ______________________________

Sim Zacks <si*@compulab.co.il> writes:
/*Here is the virtual table I mentioned using select * on a join*/
(select * from PackagePricingGroups b Inner JOIN PricingGroups c ON b.PricingGroupID = c.PricingGroupID) groups


Okay, evidently the problem is that you have identically named
columns in the two tables PackagePricingGroups and PricingGroups,
so the "groups" join contains duplicate column names. (AFAICS this
is not illegal per the SQL spec, but I wonder whether it shouldn't
be, because it's very hard to avoid ambiguity.)

I've tweaked ruleutils.c for 8.0 so that the display looks like

....
LEFT JOIN ( SELECT b.packagepricinggroupid, b.pricinggroupid,
b.packageid, b.createuserid, b.createdate, b.modifyuserid,
b.modifydate, c.pricinggroupid, c.description,
c.supplierid, c.baseprice, c.priceperpin, c.currencyid,
c.createuserid, c.createdate, c.modifyuserid, c.modifydate
FROM packagepricinggroups b
JOIN pricinggroups c ON
....

which solves this particular issue. I'm not sure a complete solution is
possible in the presence of duplicate column names; perhaps you should
modify the query to avoid that.

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

Nov 23 '05 #5
On second thought another way to optimize a query like that would be
to remove the * and only put in the columns that are actually being
used, as opposed to taking the * literally.
Such that if the fields in the select list use 2 columns and the join
uses 1 column, only those 3 columns should be expanded by the
optimizer. This would probably make the query more efficient as well,
being that it selects fewer fields.

Thank You
Sim Zacks
IT Manager
CompuLab
04-829-0145 - Office
04-832-5251 - Fax
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 23 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Anton Noll | last post by:
We are using Visual Studio 2003.NET (C++) for the development of our software in the fields digital signal processing and numerical acoustics. One of our programs was working correctly if we are...
4
by: Neil | last post by:
I just resolved a strange situation I was having with an ODBC linked SQL 7 view in an Access 2000 MDB file, and I'm trying to get some understanding as to what happened. The linked view was...
6
by: Thorsten Raasch | last post by:
Hi, the following C++ program seems to yield a segmentation fault in g++ 3.4 when compiled with any of the optimization options -O*, e.g. with "g++ -O2 bug.cpp -o bug". class TestClass {...
19
by: Martin Oddman | last post by:
Hi, I have a compiling problem. Please take a look at the code below. I have an application that is built upon three tiers: one data tier (Foo.DataManager), one business tier (Foo.Kernel) and...
19
by: Jerry | last post by:
I managed to narrow this down to a very simple expression. try this: private void Bug() { bool b = false; Test(3, (b || b) && b && !b); } private void Works() {
1
by: Christian | last post by:
I'm new to this list so please forgive in case this is not the correct forum. If so, please let me know to where I can direct bug reports for vc. The following crashes using whole program...
0
by: Glen Parker | last post by:
8.0 beta1 does not run on Windows 2000 Terminal Server. This is the http://pgfoundry.org/projects/pginstaller/ download from 08/09/2004. It ran OK for me on Win2K Pro, so I suspect this is...
3
by: Abhishek | last post by:
Recently i found that my C++ program was running fine with no optimization and giving segmentation fault with error code 139 when compiled with optimization level 2. I searched somewhat but never...
38
by: Mark Dickinson | last post by:
I get the following behaviour on Python 2.5 (OS X 10.4.8 on PowerPC, in case it's relevant.) (0.0, 0.0) (-0.0, -0.0) I would have expected y to be -0.0 in the first case, and 0.0 in the...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.