Re: RFD: schemas and different kinds of Postgres objects
От | Tom Lane |
---|---|
Тема | Re: RFD: schemas and different kinds of Postgres objects |
Дата | |
Msg-id | 8842.1011822361@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: RFD: schemas and different kinds of Postgres objects (Bill Studenmund <wrstuden@netbsd.org>) |
Ответы |
Re: RFD: schemas and different kinds of Postgres objects
(Bill Studenmund <wrstuden@netbsd.org>)
Re: RFD: schemas and different kinds of Postgres objects (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Bill Studenmund <wrstuden@netbsd.org> writes: >> No, you're missing the point. Which of x,y,z,p,q is the name we >> are going to test to see if it is a table or function? > No, I'm not. :-) You test enough of them to figure out what case you have. 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. > Actually, it's not that hard. In foo.funcname, do we support anything > AFTER the funcname? I don't think so. If there were a parenthesis, then we > have a function call. If it's an operator or something else, we have > either a table reference, or a foo.funcname function call. So all we have > to do is see if p.q (last two elements) is a schema.function, or of q is a > function pathed into our current schema. If yes, we have foo.function. If > not, then we have some table reference. Now wait a sec. What you started out with was the claim > Why not? What's wrong with either schema.foo.function (==> > function(schema.foo)) or foo.schema.function (==> schema.function(foo))? The issue was not figuring out whether the last component was a function name or not, it was to determine what the other components were, and in particular whether the function name should be presumed to be qualified (by the next-to-last component taken as a schema name) or unqualified. That in turns changes your assumptions about which of the components further left are table names, schema names, or catalog names. > ... I don't think working with real > schemas will be that hard. So why not just do things right from the > begining? If I thought that SQL's model of ownership == namespace was "right", then we probably wouldn't be having this argument. I think the spec pretty much sucks in this particular department, and I don't see why we should restrict our implementation to support only the spec's braindead world view. Especially not when it makes the implementation harder, not easier, because we end up needing to add in weird frammishes to have some semblance of backwards-compatibility too. Please give me some good reasons (not "the spec says so") why it's a good idea to treat ownership of a namespace as equivalent to ownership of the objects in it, and why decoupling the concepts at the implementation level isn't a reasonable thing to do. regards, tom lane
В списке pgsql-hackers по дате отправления: