Обсуждение: Where to submit a bug report?

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

On Tue, May 04, 2004 at 18:50:09 +0000,
  Bradley Kieser <brad@kieser.net> wrote:
> 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".

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

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.

On Tue, 4 May 2004, Bruno Wolff III wrote:

> On Tue, May 04, 2004 at 18:50:09 +0000,
>   Bradley Kieser <brad@kieser.net> wrote:
> > 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".
>
> >
> > 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.
>
> 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.