pg_stat_reset round 2
This is a reworked patch. It makes pg_stat_reset() a documented builtin
function. It requires superuser privileges to execute. The committer
should check my pg_proc.h entry to make sure I've set isstrict, volatility,
etc. correctly...
It's been renamed in line with the other stats functions.
Chris
Attachments:
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
This is a reworked patch. It makes pg_stat_reset() a documented builtin
function. It requires superuser privileges to execute. The committer
should check my pg_proc.h entry to make sure I've set isstrict, volatility,
etc. correctly...
It should be marked volatile (rather than stable), as it has
side-effects.
Wouldn't PG_RETURN_VOID() be more appropriate than returning true?
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
It should be marked volatile (rather than stable), as it has
side-effects.
OK, I'll fix it.
Wouldn't PG_RETURN_VOID() be more appropriate than returning true?
I was under the impression that functions used in SELECTs cannot use
PG_RETURN_VOID()...
Chris
OK, I've attached a new patch where the function is marked volatile. I
tested and you cannot have the function returning void, so I left it
returning boolean.
Chris
Show quoted text
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org]On Behalf Of Christopher
Kings-Lynne
Sent: Monday, 5 August 2002 4:00 PM
To: Neil Conway
Cc: Patches
Subject: Re: [PATCHES] pg_stat_reset round 2It should be marked volatile (rather than stable), as it has
side-effects.OK, I'll fix it.
Wouldn't PG_RETURN_VOID() be more appropriate than returning true?
I was under the impression that functions used in SELECTs cannot use
PG_RETURN_VOID()...Chris
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Attachments:
Interesting that all callable function must return a type. I did:
test=> select proname from pg_proc where prorettype = 0;
and none of the functions with 0 prorettype can be called from psql. I
guess boolean is the best we can do. I guess because it is a function
it has to return something.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
OK, I've attached a new patch where the function is marked volatile. I
tested and you cannot have the function returning void, so I left it
returning boolean.Chris
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org]On Behalf Of Christopher
Kings-Lynne
Sent: Monday, 5 August 2002 4:00 PM
To: Neil Conway
Cc: Patches
Subject: Re: [PATCHES] pg_stat_reset round 2It should be marked volatile (rather than stable), as it has
side-effects.OK, I'll fix it.
Wouldn't PG_RETURN_VOID() be more appropriate than returning true?
I was under the impression that functions used in SELECTs cannot use
PG_RETURN_VOID()...Chris
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
OK, I've attached a new patch where the function is marked volatile. I
tested and you cannot have the function returning void, so I left it
returning boolean.Chris
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org]On Behalf Of Christopher
Kings-Lynne
Sent: Monday, 5 August 2002 4:00 PM
To: Neil Conway
Cc: Patches
Subject: Re: [PATCHES] pg_stat_reset round 2It should be marked volatile (rather than stable), as it has
side-effects.OK, I'll fix it.
Wouldn't PG_RETURN_VOID() be more appropriate than returning true?
I was under the impression that functions used in SELECTs cannot use
PG_RETURN_VOID()...Chris
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Interesting that all callable function must return a type. I did:
test=> select proname from pg_proc where prorettype = 0;
and none of the functions with 0 prorettype can be called from psql. I
guess boolean is the best we can do. I guess because it is a function
it has to return something.
Yeah, because otherwise what does the SELECT return? It has to return at
least one column? It would be odd to just go SELECT blah() and have the
prompt just come back to you. However, it would be nice to be able to go
"CALL blah()" and have it return nothing except maybe a 'CALL' string.
Chris
Christopher Kings-Lynne dijo:
Interesting that all callable function must return a type. I did:
test=> select proname from pg_proc where prorettype = 0;
and none of the functions with 0 prorettype can be called from psql. I
guess boolean is the best we can do. I guess because it is a function
it has to return something.Yeah, because otherwise what does the SELECT return? It has to return at
least one column? It would be odd to just go SELECT blah() and have the
prompt just come back to you. However, it would be nice to be able to go
"CALL blah()" and have it return nothing except maybe a 'CALL' string.
What's so bad about returning a SQL NULL in SELECT ? Seems an arbitrary
limitation to me.
--
Alvaro Herrera (<alvherre[a]atentus.com>)
"El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens)
Alvaro Herrera wrote:
Christopher Kings-Lynne dijo:
Interesting that all callable function must return a type. I did:
test=> select proname from pg_proc where prorettype = 0;
and none of the functions with 0 prorettype can be called from psql. I
guess boolean is the best we can do. I guess because it is a function
it has to return something.Yeah, because otherwise what does the SELECT return? It has to return at
least one column? It would be odd to just go SELECT blah() and have the
prompt just come back to you. However, it would be nice to be able to go
"CALL blah()" and have it return nothing except maybe a 'CALL' string.What's so bad about returning a SQL NULL in SELECT ? Seems an arbitrary
limitation to me.
Functions can return NULL, just not void.
The CALL syntax Chris is referring to is for Procedures, which we have
not implemented yet (but I'd love to see us do it). Procedures return
nothing. They have side efects only. Well, actually, in other DBs there
are OUT parameters which allow procedures to return values in a limited
way. And in MSSQL (at least) they can project result sets, which is not
the same as returning result sets because you can't do anything with
them like apply a criteria or join with other results.
Joe
The CALL syntax Chris is referring to is for Procedures, which we have
not implemented yet (but I'd love to see us do it). Procedures return
nothing. They have side efects only. Well, actually, in other DBs there
are OUT parameters which allow procedures to return values in a limited
way. And in MSSQL (at least) they can project result sets, which is not
the same as returning result sets because you can't do anything with
them like apply a criteria or join with other results.
SQL9x defines IN, OUT, and INOUT parameters on procedures. Now that we
have set returning functions, we might (more easily?) be able to define
tuple-returning procedures which is presumably how we would implement
OUT parameters (similar to how python returns values).
- Thomas
I am rejecting this version of the patch because you are working out the
issues.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
OK, I've attached a new patch where the function is marked volatile. I
tested and you cannot have the function returning void, so I left it
returning boolean.Chris
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org]On Behalf Of Christopher
Kings-Lynne
Sent: Monday, 5 August 2002 4:00 PM
To: Neil Conway
Cc: Patches
Subject: Re: [PATCHES] pg_stat_reset round 2It should be marked volatile (rather than stable), as it has
side-effects.OK, I'll fix it.
Wouldn't PG_RETURN_VOID() be more appropriate than returning true?
I was under the impression that functions used in SELECTs cannot use
PG_RETURN_VOID()...Chris
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073