Re: RFD: schemas and different kinds of Postgres objects
От | Peter Eisentraut |
---|---|
Тема | Re: RFD: schemas and different kinds of Postgres objects |
Дата | |
Msg-id | Pine.LNX.4.30.0201250013040.686-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: RFD: schemas and different kinds of Postgres objects (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: RFD: schemas and different kinds of Postgres objects
|
Список | pgsql-hackers |
Tom Lane writes: > There could be multiple valid interpretations. When you can't even > figure out where to start, it's too squishy for me. Code complexity > isn't really the issue here, it's whether a user can understand what's > going on. Here's a tricky question: In what situations is a.b valid to mean b(a)? Because in a general object-like system you could write a.b.c.d to mean d(c(b(a))). There you've got a system where it's really impossible to tell anything. Maybe b() returns a table, so a.b.c.d could mean subattribute d in column c in the table returned by b(a). Somehow we need to do at least one of three things: 1. Require parentheses after function calls. 2. Use a different operator to invoke function calls (SQL uses ->). 3. Require users to register functions as "methods" with the data type before being able to say a.b for b(a). This also takes care of having to specify the schema of b because that's declared when you define the method. SQL99 does 2 and 3 (but not 1). I say, forget Oracle. Oracle doesn't have all the extensibility functionality that PostgreSQL has. Let's build a system that is consistent, orthogonal, and easy to use for *our* users, and those that want to convert will quickly see the value. -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: