On Fri, 26 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > I guess to get at my point, I can ask this question, "Will schema support
> > invalidate existing PostgreSQL database designs."
> >
> > I would like the answer to be no. I would like our users to be able to
> > dump a pr
Bill Studenmund writes:
> I guess to get at my point, I can ask this question, "Will schema support
> invalidate existing PostgreSQL database designs."
>
> I would like the answer to be no. I would like our users to be able to
> dump a pre-schema-release db, upgrade, and then restore into a
> sch
* Bill Studenmund <[EMAIL PROTECTED]> wrote:
| I would like the answer to be no. I would like our users to be able to
| dump a pre-schema-release db, upgrade, and then restore into a
| schema-aware PostgreSQL. And have their restore work.
Important point. Also having a standard is fine, but by
On Thu, 25 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > Mainly because when we introduce schemas, all SQL transactions will have
> > to be performed in the context of *some* schema. I think "DEFAULT" was the
> > name you mentioned for when there was no schema matching the us
Bill Studenmund writes:
> > Because SQL says so. All objects in a schema belong to the owner of the
> > schema. In simple setups you have one schema per user with identical
> > names. This has well-established use patterns in other SQL RDBMS.
>
> Then implimenting schemas will cause a backward
On Tue, Oct 23, 2001 at 08:43:32AM -0700, Bill Studenmund wrote:
>
> And there's the fact that schemas were wanted for 7.2, and didn't happen.
> Withouth external adgitation, will they happen for 7.3? Given the size of
> the job, I understand why they didn't happen (the package changes so far
> r
On Wed, 24 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > So I am a "naive" programmer because I mention intent above?
>
> No.
Sorry, that's the way it came across. As you've said that was not your
intent, please disregard my response; I was responding to something you
did not
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?
>
> Ope
On Tue, 23 Oct 2001, Thomas Lockhart wrote:
> (I've been following the thread, at least casually ;)
>
> > 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
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.
> Conceptually the main determiner of what function you want is the name,
(I've been following the thread, at least casually ;)
> Why? Operators are used differently than functions. That strikes me as a
> good reason to namespace them differently.
> Conceptually the main determiner of what function you want is the name, at
> least as far as from what I can tell from ta
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
On Sun, 21 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > The big one for now is how should you log into one schema or another?
> > psql database.schema ?
>
> Each user has a default schema, which is by default the schema with the
> same name as the user name, or if no such sch
Bill Studenmund writes:
> The big one for now is how should you log into one schema or another?
> psql database.schema ?
Each user has a default schema, which is by default the schema with the
same name as the user name, or if no such schema exists, it's the DEFAULT
schema (which I believe is wh
On Tue, 16 Oct 2001, Bill Studenmund wrote:
> I still think that schemas and packages are different, but I now think
> they are interrelated. And that it shouldn't be too hard to leverage the
> package work into schema support. Still a lot of work, but the package
> work has shown how to go from
On Fri, 19 Oct 2001, Tom Lane wrote:
> Yeah. I am wondering whether we couldn't support Oracle-style packages
> as a thin layer of syntactic sugar on top of schemas. I am concerned
> about the prospect that "foo.bar" might mean either "object bar in
> schema foo" or "object bar in package foo".
On 19 Oct 2001, Gunnar [iso-8859-1] Rønning wrote:
> * Tom Lane <[EMAIL PROTECTED]> wrote:
> |
> | Yeah. I am wondering whether we couldn't support Oracle-style packages
> | as a thin layer of syntactic sugar on top of schemas. I am concerned
> | about the prospect that "foo.bar" might mean eit
On 19 Oct 2001, Gunnar [iso-8859-1] Rønning wrote:
> * Bill Studenmund <[EMAIL PROTECTED]> wrote:
> |
> | Packages aren't schemas. What they bring to the table is they facilitate
> | making stored procedures (functions). You can have twelve different
> | developers working on twenty different pac
* Tom Lane <[EMAIL PROTECTED]> wrote:
|
| > resources as well that should not conflict with other packages, like temp
| > tables or such. It then seems to me that using schemas can solve everything
| > that packages do and more ?
|
| Yeah. I am wondering whether we couldn't support Oracle-style
Gunnar =?iso-8859-1?q?R=F8nning?= <[EMAIL PROTECTED]> writes:
> Hmm. But if we had schema support can't we just package those procedures
> into a schema with a given name ? Maybe my stored procedures needs some other
> resources as well that should not conflict with other packages, like temp
> tab
* Bill Studenmund <[EMAIL PROTECTED]> wrote:
|
| Packages aren't schemas. What they bring to the table is they facilitate
| making stored procedures (functions). You can have twelve different
| developers working on twenty different packages, with no fear of name
| conflicts. The package names wil
On Sat, 13 Oct 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> writes:
> > The other choice is to just give the function's name. The first place
> > Postgres will look is in the package context used for parsing. If it's not
> > there (and that context wasn't "standard"), then it will
On Sun, 14 Oct 2001, Bill Studenmund wrote:
> On Mon, 15 Oct 2001, Tom Lane wrote:
>
> > Bill Studenmund <[EMAIL PROTECTED]> writes:
> > > For the most part, I think packages and schemas are orthogonal. I'm taking
> > > a cue from Oracle here. Oracle considers packages to be a schema-specific
> >
Bill Studenmund <[EMAIL PROTECTED]> writes:
> For the most part, I think packages and schemas are orthogonal. I'm taking
> a cue from Oracle here. Oracle considers packages to be a schema-specific
> object.
Nonetheless, it's not clear to me that we need two independent concepts.
Given a name sear
On Mon, 15 Oct 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> writes:
> > For the most part, I think packages and schemas are orthogonal. I'm taking
> > a cue from Oracle here. Oracle considers packages to be a schema-specific
> > object.
>
> Nonetheless, it's not clear to me that we
On Mon, 15 Oct 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> writes:
> > For the most part, I think packages and schemas are orthogonal. I'm taking
> > a cue from Oracle here. Oracle considers packages to be a schema-specific
> > object.
>
> Nonetheless, it's not clear to me that we
26 matches
Mail list logo
