Thread: 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
Attachment
"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 > -----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 2 > > > > 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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
Attachment
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 2
> >
> >
> > > 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
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
[ 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 19026
Your 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 2
> >
> >
> > > 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
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
[ 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 19026
> 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. 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 2 > > > > > > > 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 > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > [ 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