Обсуждение: How do I disable: Adding missing FROM-clause

I know that PSQL has the cool feature of doing: Adding missing FROM-clause

But I want to disable it, because its silent adding can allow a bad SQL statement to execute a
cartesian select (when in fact it should error out).

I searched and found references to changing the postgresql.conf with:
add_missing_from = false
enable_implicited_join = false

But neither one of these seems to disable the functionality (I did a reload after making the change)

Do I have to completely stop the db to make the change?  Or is there something else I should be
doing to disable it?

Thanks

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry@greatgulfhomes.com
Fax: (416) 441-9085

<terry@ashtonwoodshomes.com> writes:
> I searched and found references to changing the postgresql.conf with:
> add_missing_from = false

This is correct.

> enable_implicited_join = false

This is not.

> But neither one of these seems to disable the functionality (I did a reload after making the change)

I'm betting that the postmaster is ignoring the file completely because
of the bogus enable_implicited_join variable.  Did you look for errors
in the postmaster log?

            regards, tom lane

Tom Lane wrote:
> <terry@ashtonwoodshomes.com> writes:
>
>>I searched and found references to changing the postgresql.conf with:
>>add_missing_from = false
>
>
> This is correct.


Just a suggestion about this:

how about implementing more options like
off/false, cross (join), natural (join)

Thought about this when reading
http://en.wikipedia.org/wiki/PostgreSQL

This site says:
| A typical search might look like this:
|
| SELECT u.* FROM user u, address a WHERE a.city='New York'
| AND a.user_name=u.user_name
|
| PostgreSQL can explicitly define the relationship between users
| and addresses. Once defined, the address becomes a property of
| the user, so the search can be greatly simplified to:
|
| SELECT * FROM user WHERE address.city='New York'

This example isn't working for me "as it is".
What relationships have to be defined and how?
Normal foreign keys aren't working.

Can anybody tell me how to accomplish this?


Thanks in advance

Sebastian

On Fri, Sep 24, 2004 at 10:41:04AM +0200, Sebastian Böck wrote:
> Thought about this when reading
> http://en.wikipedia.org/wiki/PostgreSQL
>
> This site says:
> | A typical search might look like this:
> |
> | SELECT u.* FROM user u, address a WHERE a.city='New York'
> | AND a.user_name=u.user_name
> |
> | PostgreSQL can explicitly define the relationship between users
> | and addresses. Once defined, the address becomes a property of
> | the user, so the search can be greatly simplified to:
> |
> | SELECT * FROM user WHERE address.city='New York'
>
> This example isn't working for me "as it is".
> What relationships have to be defined and how?
> Normal foreign keys aren't working.

I'm pretty sure this is wrong. I've never seen anything in PostgreSQL
that might do what that bit says. There are some other inaccuracies too
I think.
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Fri, Sep 24, 2004 at 10:41:04AM +0200, Sebastian B=F6ck wrote:
>> Thought about this when reading
>> http://en.wikipedia.org/wiki/PostgreSQL
>> |
>> | PostgreSQL can explicitly define the relationship between users
>> | and addresses. Once defined, the address becomes a property of
>> | the user, so the search can be greatly simplified to:
>> | SELECT * FROM user WHERE address.city='New York'

> I'm pretty sure this is wrong. I've never seen anything in PostgreSQL
> that might do what that bit says.

It's possible that this is an accurate description of something that
would work back in the PostQUEL days.  It's certainly bogus now, though.
Anyone want to go fix it?

            regards, tom lane