On 09/24/2018 10:09 AM, Joe Conway wrote:
> On 09/24/2018 10:01 AM, Tom Lane wrote:
>> Joe Conway writes:
>>> Having seen none, committed/pushed. This did not seem worth
>>> back-patching, so I only pushed to master.
>>
>> I don't see anything on gitmaster?
>
> Hmm, yes, interesting -- I must of
On 09/24/2018 10:01 AM, Tom Lane wrote:
> Joe Conway writes:
>> Having seen none, committed/pushed. This did not seem worth
>> back-patching, so I only pushed to master.
>
> I don't see anything on gitmaster?
Hmm, yes, interesting -- I must of messed up my local git repo somehow.
Will try again.
Joe Conway writes:
> Having seen none, committed/pushed. This did not seem worth
> back-patching, so I only pushed to master.
I don't see anything on gitmaster?
regards, tom lane
On 09/21/2018 01:51 PM, Joe Conway wrote:
> On 09/19/2018 11:18 AM, Joe Conway wrote:
>> On 09/19/2018 10:54 AM, Tom Lane wrote:
>>> So maybe what we really need is a table of operators not functions.
>>
>> Good idea -- I will take a look at that.
>>
>>> However, I don't object to documenting any
On 09/19/2018 11:18 AM, Joe Conway wrote:
> On 09/19/2018 10:54 AM, Tom Lane wrote:
>> Joe Conway writes:
>>> * I do believe aclitemeq() has utility outside internal purposes.
>>
>> Our normal policy is that we do not document functions that are meant to
>> be invoked through operators. The \df
On 09/19/2018 12:30 PM, John Naylor wrote:
> On 9/19/18, Tom Lane wrote:
>> However, I don't object to documenting any function that has its
>> own pg_description string.
>
> Speaking of, that description string seems to have been neglected.
> I've attached a remedy for that.
Thanks, will take c
On 9/19/18, Tom Lane wrote:
> However, I don't object to documenting any function that has its
> own pg_description string.
Speaking of, that description string seems to have been neglected.
I've attached a remedy for that.
-John Naylor
diff --git a/src/include/catalog/pg_proc.dat b/src/include/
Hello,
Our normal policy is that we do not document functions that are meant to
be invoked through operators. The \df output saying that is sufficient:
The output of \df is one thing, but I was looking at pg online
documentation and hoping to find things as well.
\dfS returns nearly 3000
On 09/19/2018 10:54 AM, Tom Lane wrote:
> Joe Conway writes:
>> * I do believe aclitemeq() has utility outside internal purposes.
>
> Our normal policy is that we do not document functions that are meant to
> be invoked through operators. The \df output saying that is sufficient:
> I would st
Joe Conway writes:
> * I do believe aclitemeq() has utility outside internal purposes.
Our normal policy is that we do not document functions that are meant to
be invoked through operators. The \df output saying that is sufficient:
# \df+ aclitemeq
On 08/03/2018 09:04 AM, Fabien COELHO wrote:
> Here is a version of the patch which documents briefly all aclitem-related
> functions, in a separate table.
I claimed this patch for review and commit. Comments:
---
* There is a comment in src/backend/utils/adt/acl.c noting that
acldefault is "no
Here is a version of the patch which documents briefly all aclitem-related
functions, in a separate table.
--
Fabien.diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index edc9be92a6..c81e5aa1b4 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -16829,6 +16829,151
postgres=# \df acl*
List of fun
Schema | Name | Result data type |
+-+--+--
pg_catalog | aclcontains | boolean | aclitem[], aclitem
pg_catalog | acldefault | aclitem[] | "char", oid
pg_catalog
Hello,
However, the point of having hidden and/or undocumented functions fails me:
they are hard/impossible to find if you do not know they exist from
the start, and if you ever find one you do not know what they do without
reading the source code in detail, eg to know what to give arguments
On Wed, Aug 01, 2018 at 04:41:44PM +0300, Pavel Luzanov wrote:
> postgres=# \df acl*
> List of fun
> Schema | Name | Result data type |
> +-+--+--
> pg_catalog | aclcontains | boolean | aclitem[], aclitem
Hello Fabien,
However, the point of having hidden and/or undocumented functions
fails me: they are hard/impossible to find if you do not know they
exist from
the start, and if you ever find one you do not know what they do
without reading the source code in detail, eg to know what to give
arg
Hello Pavel,
I couldn't find the documentation. Attached patch adds one.
Probably this function should have been named pg_*. Too late.
I think this is intentionally hidden function, like others started with acl*.
Yep, I thought of that.
However, the point of having hidden and/or undocumen
Fabien,
On 01.08.2018 15:28, Fabien COELHO wrote:
I couldn't find the documentation. Attached patch adds one.
Probably this function should have been named pg_*. Too late.
I think this is intentionally hidden function, like others started with
acl*.
postgres=# \df acl*
List of fun
S
I couldn't find the documentation. Attached patch adds one.
Probably this function should have been named pg_*. Too late.
--
Fabien.diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index edc9be92a6..0e5f8b914b 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1639
19 matches
Mail list logo