On Mon, Dec 18, 2006 at 12:15:34AM +1100, Brendan Jurd wrote:
> On 12/17/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >But having said all that, I think there are bits of SQL2003 that do some
> >of what you're after. I don't think anyone has looked hard at what
> >would be involved in merging those n
On 12/17/06, Tom Lane <[EMAIL PROTECTED]> wrote:
But having said all that, I think there are bits of SQL2003 that do some
of what you're after. I don't think anyone has looked hard at what
would be involved in merging those new SQL features with historical
Postgres behaviors.
I've been looking
I wholeheartedly support the approach BJ is advocating.
The notion that methods (functions) and variables (tables)
can be defined together is a very useful OO approach.
I too find it difficult to recall which functions "belong"
to which tables. Of course, some of my functions are very
generic and
On 12/17/06, Tom Lane <[EMAIL PROTECTED]> wrote:
90% of the value this would have is already available with views,
I think, without going outside bog-standard SQL:
Views also work fine, but one of the big advantages of having table
methods is that all the things your table can do are contained
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> That works fine, but wouldn't it be far more elegant if you could do
> this instead:
> CREATE TABLE person (
> id SERIAL PRIMARY KEY,
> firstname TEXT NOT NULL,
> lastname TEXT NOT NULL,
> FUNCTION name() RETURNS text AS $$ SELECT firstname || ' ' |
In the object-relational context, the definition of a "relation" is
much the same as the idea of a "class"; the columns in a table are
analogous to the attributes of a class. The names of Postgres' system
catalogs reflect this correlation (pg_class, pg_attribute).
Likewise, each tuple within a r
