Re: schema support, was Package support for Postgres
От | Bill Studenmund |
---|---|
Тема | Re: schema support, was Package support for Postgres |
Дата | |
Msg-id | Pine.NEB.4.33.0110220647420.6662-100000@vespasia.home-net.internetconnect.net обсуждение исходный текст |
Ответы |
Re: schema support, was Package support for Postgres
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | pgsql-hackers |
On Tue, 23 Oct 2001, Peter Eisentraut wrote: > Bill Studenmund writes: > > > Why? Operators are used differently than functions. > > I don't think so. Operators are a syntacticaly convenience for functions. > That's what they always have been and that's what they should stay. How does what you say disagree with what I said? Operators certainly have a lot more structure to them than a function call does. That's why you give the restriction and join functions, and you hand them commutation and negation operators. The optimizer uses all of these tools to make what you want to have happen (adding for instance) happen as efficiently as possible. It will re-write what you said in a different manner, if that different manner holds the same intent yet is more efficient. > > Conceptually the main determiner of what function you want is the name, at > > least as far as from what I can tell from talking with all the programmers > > I know. Yes, we make sure the types match (are part of the primary key), > > but the name is the main concept. Operators, however, are more > > intent-based. The '+' operator means I want these two things added > > together. I don't care so much what types are involved, I want adding to > > happen. That's a difference of intent. And that's the reason that I think > > different namespacing rules make sense. > > Naive developers all program by "intent". If I invoke a + operator then I > expect it to add. If I call a sqrt() function then I expect it to > calculate the square root. If I execute an INSERT statement then I would > prefer that I did not delete anything. Designing systems to work by > "intent" can be construed as an aspect of "user-friendliness". > > But the more knowledgeable programmer is mildly aware of what's going on > behind the scenes: Both "+" and "sqrt" are just names for function code > that may or may not do what you think they do. So this applies to both > functions and operators. So I am a "naive" programmer because I mention intent above? That is very condescending, Peter, and strikes me as inappropriate. Are you really so out of things to say that you have to resort to condescension? At what point have you tried to determine how experienced a programmer I am? You've never asked me for my resume, or what projects I've worked on before this. Your comments indicate to me that you have not yet tried the patch I sent in, and if you have, I really doubt you've made packages with it. So how can you judge? The fact I disagree with you? Also, in your "naive" vs "more knowledgeable" programmer comparison, you mention "user-friendliness" in the "naive" part, the "bad" part. Do you really think that "user-friendliness" is a bad thing? I hope not. I think that "user-friendliness" is an important part of programming. It means that your tools or programmatic interfaces have (or lack) an appropriateness to the task at hand. It's not just for command lines or GUIs. I've worked with different libraries and programming packages, and I have experienced the ones where the design and layout make the library/package useful, and ones where the design and layout get in the way. Hmmm... Thining about it, I now think you're right, that we should have a way to handle pathing. A package author should be able to set the path used for routines in the package, though. > > > The built-in schemas is called DEFINITION_SCHEMA. > > > > Why is it different from the "DEFAULT" you get when you log into a > > database which doesn't have a schema whose name matches your username? > > Because SQL says so. Actually I'm not so sure. See the note to Thomas, especially the last sentance of section 21.1. It seems that if we have an INFORMATION_SCHEMA which contains all the views in the spec, and our system tables have the right behaviors, then we are fine. Actually, the text in section 20.1, "Introduction to Information Schema and Definition Schema" is more direct: "The views of the Information Schema are viewed tables defined in terms of the base tables of the Definition Schema. The only purpose of the Definition Schema is to provide a data model to support the Information Schema and to assist understanding. An SQL-implementation need do no more than simulate the existance of the Definition Schema as viewed through the Information Schema views." So if we have INFORMATION_SCHEMA with the right vies in it, we are fine doing whatever we want. > > Not necessarily. A user other than the one who owns the schema can add a > > package to it. It's the same thing as why we keep track of who added a > > function. :-) > > Blech, I meant "you can replace the owner column with the schema column". That's actually what I thought you said. :-) I stil think we can't do that, since someone other than the schema owner can add a package to a schema. :-) Or at least that's the assumption I'm running on; we allow users other than PGUID to create functions (and operators and aggregates and types) in the default (whatever it will be called) schema, so why shouldn't they be allowed to add packages? Take care, Bill
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: [GENERAL] Using an SMP machine to make multiple indices on the same table