From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Neil Conway" <nconway(at)klamath(dot)dyndns(dot)org>, "Karel Zak" <zakkr(at)zf(dot)jcu(dot)cz> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: getpid() function |
Date: | 2002-08-02 01:13:06 |
Message-ID: | GNELIHDDFBOCMGBFGEFOKEHJCDAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> No, there isn't (for example, pg_stat_backend_id() versus
> current_schema() -- or pg_get_viewdef() versus obj_description() ).
> Now that we have table functions, we might be using more built-in
> functions to provide information to the user -- so there will be
> an increasing need for some kind of naming convention for built-in
> functions. However, establishing a naming convention without
> breaking backwards compatibility might be tricky.
I personally think that as many functions as possible should be prefixed
pg_*... People are still used to avoiding pg_ as a prefix.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Manuel Cano Muñoz | 2002-08-02 01:33:19 | Re: Referential integrity doesn't work? (Thanks a lot) |
Previous Message | Cédric Dufour | 2002-08-01 23:47:36 | b1 OR b2 <-> ( CASE WHEN b1 THE true ELSE b2 END ): performance bottleneck on logical OR |
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-08-02 01:37:43 | Re: Module Portability |
Previous Message | Greg Copeland | 2002-08-02 00:43:31 | Re: CVS server problem! |