Where to submit a bug report?

[Bradley Kieser]

Hi All,

Is this the correct place to submit a bug report or should I do it
somewhere else?

BUG DETAILS:

PG version 7.4.2
Platform: Linux

BUG DESC:

Using aliases in the "select" part of a select clause isn't strongly
checked against the alias definitions in the FROM part of the SQL.
Specifically, if the alias in the "select" clause matches another table
name (not in the FROM list), then the select is applied against that
other table whereas the correct action would be to chuck and error.

EXAMPLE:

One table: acct_dets
One view: acct_dets_view created as select * from acct_dets_table where XXXX

Select acct_dets.aaa, acct_dets.bbb from acct_dets_view;

The above select is accepted and processed when it SHOULD throw an error.

This was discovered using JBuilderX and JBDC when a baseline table was
moved into a view to add security constraints to the dataset. It is a
feature of JB that is always pre-pends the table name as an alias in the
select clause, so the name change to the _view part changed in the FROM
clause but (my error) I forgot to change the select columns in one of
the queries. The result was that the view was bypassed.

Thanks,

Brad

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

[Bruno Wolff III]

On Tue, May 04, 2004 at 18:50:09 +0000,

Post by Bradley Kieser
Hi All,
Is this the correct place to submit a bug report or should I do it
somewhere else?

Bugs go to pgsql-bugs, how I don't think this is really a bug, but
a "feature".

Post by Bradley Kieser
PG version 7.4.2
Platform: Linux
Using aliases in the "select" part of a select clause isn't strongly
checked against the alias definitions in the FROM part of the SQL.
Specifically, if the alias in the "select" clause matches another table
name (not in the FROM list), then the select is applied against that
other table whereas the correct action would be to chuck and error.
One table: acct_dets
One view: acct_dets_view created as select * from acct_dets_table where XXXX
Select acct_dets.aaa, acct_dets.bbb from acct_dets_view;
The above select is accepted and processed when it SHOULD throw an error.

Postgres has a feature where tables not listed in FROM clauses get silently
included. There is something that turns this off, but I think it is
only available in the development version. This feature is really only
useful for delete where there isn't a syntax to specify addition tables
and you need to use a subquery instead. A number of people didn't like the
way it works now as that usually when you end up using this feature
it is a mistake in the query rather than intentional use.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[scott.marlowe]

Post by Bruno Wolff III
On Tue, May 04, 2004 at 18:50:09 +0000,

Post by Bradley Kieser
Hi All,
Is this the correct place to submit a bug report or should I do it
somewhere else?

Bugs go to pgsql-bugs, how I don't think this is really a bug, but
a "feature".

Post by Bradley Kieser
PG version 7.4.2
Platform: Linux
Using aliases in the "select" part of a select clause isn't strongly
checked against the alias definitions in the FROM part of the SQL.
Specifically, if the alias in the "select" clause matches another table
name (not in the FROM list), then the select is applied against that
other table whereas the correct action would be to chuck and error.
One table: acct_dets
One view: acct_dets_view created as select * from acct_dets_table where XXXX
Select acct_dets.aaa, acct_dets.bbb from acct_dets_view;
The above select is accepted and processed when it SHOULD throw an error.

Postgres has a feature where tables not listed in FROM clauses get silently
included. There is something that turns this off, but I think it is
only available in the development version. This feature is really only
useful for delete where there isn't a syntax to specify addition tables
and you need to use a subquery instead. A number of people didn't like the
way it works now as that usually when you end up using this feature
it is a mistake in the query rather than intentional use.

It's in 7.4 and it's called:

#add_missing_from = true

uncomment that and set it to false and it should error out as expected.


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