Joe Conway wrote:
> What about this:
>
> Functions returning multiple rows and/or multiple columns are
> now much easier to use than before. You can call such a
> "table function" in the SELECT FROM clause, treating its output
> like a table. Also, plpgsql functions can now return sets.
Added.
Tom Lane wrote:
> C functions have always been able to return sets too; you don't honestly
> think that a SQL function can do something a C function can't, do you?
The original dblink is an example.
>
> There are really two independent improvements here: one is the ability
> for plpgsql functio
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, now I remember, only SQL functions could return sets. How about
> this:
>PL/PgSQL and C functions can now return sets, with multiple
>rows and multiple columns. You specify these functions in the
>SELECT FROM cl
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't remember every seeing a function returning sets before. Can you
> > give an example?
>
> http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392
>
> Also, the preceding subsection shows SQL funct
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't remember every seeing a function returning sets before. Can you
> give an example?
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392
Also, the preceding subsection shows SQL functions returning rows. So
these
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Please review the HISTORY file.
>
>PostgreSQL now support ALTER TABLE ... DROP COLUMN functionality.
>
> s/support/supports/
>
>Functions can now return sets, with multiple rows
>and multiple col
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Please review the HISTORY file.
PostgreSQL now support ALTER TABLE ... DROP COLUMN functionality.
s/support/supports/
Functions can now return sets, with multiple rows
and multiple columns. You specify these functions
Joe Conway wrote:
> Bruce Momjian wrote:
> > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > I used the same HISTORY categories Peter made in 7.2. I liked them.
> >
> > Please review the HISTORY file. I am sure there are improvements that
> > can be made.
> >
Bruce Momjian wrote:
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> I used the same HISTORY categories Peter made in 7.2. I liked them.
>
> Please review the HISTORY file. I am sure there are improvements that
> can be made.
>
A few minor comments:
1. suggest
OK, wording updated to add 'applications':
Schemas allow users to create objects in their own namespace
so two people or applications can have tables with the same
name. There is also a public schema for shared tables.
Table/index creation can be restr
Alvaro Herrera wrote:
> Shridhar Daithankar dijo:
>
> > On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> >
> > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > Some minor stuff,
>
> In the schema changes description:
>
> "Schemas allow users to create objects i
Rod Taylor wrote:
> Found this line without a name:
>
> Propagate column or table renaming to foreign key constraints
>
> Is that item complete? pg_constraint follows (as such dump / restore
> will work) but the triggers themselves still break, don't they?
No idea. The item only talks about t
Tatsuo Ishii wrote:
> > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > I used the same HISTORY categories Peter made in 7.2. I liked them.
> >
> > Please review the HISTORY file. I am sure there are improvements that
> > can be made.
>
> Please change:
>
> >
> Shridhar Daithankar dijo:
>
> > On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> >
> > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > Some minor stuff,
>
> In the schema changes description:
>
> "Schemas allow users to create objects in their own namespace
Shridhar Daithankar dijo:
> On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
>
> > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> Some minor stuff,
In the schema changes description:
"Schemas allow users to create objects in their own namespace
so two people can have
Rod Taylor <[EMAIL PROTECTED]> writes:
> Found this line without a name:
> Propagate column or table renaming to foreign key constraints
> Is that item complete? pg_constraint follows (as such dump / restore
> will work) but the triggers themselves still break, don't they?
Yes, no. There's hack
Found this line without a name:
Propagate column or table renaming to foreign key constraints
Is that item complete? pg_constraint follows (as such dump / restore
will work) but the triggers themselves still break, don't they?
On Wed, 2002-09-04 at 03:24, Bruce Momjian wrote:
> OK, the HISTORY
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> I used the same HISTORY categories Peter made in 7.2. I liked them.
>
> Please review the HISTORY file. I am sure there are improvements that
> can be made.
Please change:
> Add CREATE/DROP CONVERSION, allowing lo
I assume you are not looking at the 7.3 release notes. It does take a
while for anon to get the changes.
---
Shridhar Daithankar wrote:
> On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
>
> > OK, the HISTORY file is updated,
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> I used the same HISTORY categories Peter made in 7.2. I liked them.
>
> Please review the HISTORY file. I am sure there are improvements that
> can be made.
Some minor s
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
I used the same HISTORY categories Peter made in 7.2. I liked them.
Please review the HISTORY file. I am sure there are improvements that
can be made.
--
Bruce Momjian| http://candle.pha.pa.us
21 matches
Mail list logo
