Thread: pg_stat_reset round 2

pg_stat_reset round 2

From
"Christopher Kings-Lynne"
Date:
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

Re: pg_stat_reset round 2

From
Neil Conway
Date:
"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

Re: pg_stat_reset round 2

From
"Christopher Kings-Lynne"
Date:
> 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


pg_stat_reset round 3

From
"Christopher Kings-Lynne"
Date:
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

Re: pg_stat_reset round 3

From
Bruce Momjian
Date:
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

Re: pg_stat_reset round 3

From
Bruce Momjian
Date:
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

Re: pg_stat_reset round 3

From
"Christopher Kings-Lynne"
Date:
> 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


Re: pg_stat_reset round 3

From
Alvaro Herrera
Date:
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)


Re: pg_stat_reset round 3

From
Joe Conway
Date:
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





Re: pg_stat_reset round 3

From
Thomas Lockhart
Date:
> 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

Re: pg_stat_reset round 3

From
Bruce Momjian
Date:
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