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 ex
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, ev
Sim Zacks <[EMAIL PROTECTED]> 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
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
Sim Zacks <[EMAIL PROTECTED]> 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
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 syst
