[docs] revise ORDER BY documentation

2024-03-02 Thread Dian Fay
I recently encountered some odd behavior with a query both selecting and sorting by `random()`. When I posted about it on pgsql-bugs ^1, David Johnston and Tom Lane provided some very detailed explanations as to what was happening, but weren't sure whether or where information about it could live

Re: add function argument names to regex* functions.

2024-01-10 Thread Dian Fay
On Wed Jan 10, 2024 at 9:18 AM EST, jian he wrote: > On Tue, Jan 9, 2024 at 8:52 AM Dian Fay wrote: > > > > On Mon Jan 8, 2024 at 9:26 AM EST, jian he wrote: > > > On Mon, Jan 8, 2024 at 8:44 AM Dian Fay wrote: > > > > The `regexp_replace` summary i

Re: add function argument names to regex* functions.

2024-01-08 Thread Dian Fay
On Mon Jan 8, 2024 at 9:26 AM EST, jian he wrote: > On Mon, Jan 8, 2024 at 8:44 AM Dian Fay wrote: > > The `regexp_replace` summary in table 9.10 is mismatched and still > > specifies the first parameter name as `string` instead of `source`. > > Since all the other functions

Re: add function argument names to regex* functions.

2024-01-07 Thread Dian Fay
On Thu Jan 4, 2024 at 2:03 AM EST, jian he wrote: > On Thu, Jan 4, 2024 at 7:26 AM Jim Nasby wrote: > > > > On 1/3/24 5:05 PM, Dian Fay wrote: > > > > Another possibility is `index`, which is relatively short and not a > > reserved keyword ^1. `position`

Re: add function argument names to regex* functions.

2024-01-03 Thread Dian Fay
> > Another possibility is `index`, which is relatively short and not a > > reserved keyword ^1. `position` is not as precise but would avoid the > > conceptual overloading of ordinary indices. > > I'm not a fan of "index" since that leaves the question of > whether it's 0 or 1 based. "Position"

Re: add function argument names to regex* functions.

2024-01-01 Thread Dian Fay
On Wed Dec 27, 2023 at 10:28 PM EST, jian he wrote: > On Thu, Dec 28, 2023 at 6:25 AM Peter Eisentraut wrote: > > > > On 27.12.23 17:53, jian he wrote: > > > similar to [1], add function argument names to the following functions: > > > regexp_like, regexp_match,regexp_matches,regexp_replace, > >

Re: TRIM_ARRAY

2021-03-01 Thread Dian Fay
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, failed Documentation:tested, failed This basically does what it says, and the code looks good.

Re: docs: note ownership requirement for refreshing materialized views

2018-08-17 Thread Dian Fay
Jonathan's patch seems like a good idea to me from a user POV, but then I just showed up the other day so I don't really have anything of substance to add. On 8/17/18 9:08 AM, Dave Cramer wrote: Dave Cramer On Thu, 16 Aug 2018 at 18:27, Jonathan S. Katz

Re: docs: note ownership requirement for refreshing materialized views

2018-08-16 Thread Dian Fay
Fair enough! Here's a new version. On 8/16/18 12:07 AM, Tom Lane wrote: Dian Fay writes: I feel resorting to the infinitive asks more involvement of the reader, while leading with the responsible role(s) helps shortcut the process of determining whether what follows is relevant. Efficiency

Re: docs: note ownership requirement for refreshing materialized views

2018-08-15 Thread Dian Fay
-sentence addition! On 8/15/18 9:03 PM, Michael Paquier wrote: On Wed, Aug 15, 2018 at 07:46:49PM -0400, Dian Fay wrote: hi all! I discovered today that the REFRESH MATERIALIZED VIEW documentation doesn't mention that only the owner (or a superuser) may actually perform the refresh operation

docs: note ownership requirement for refreshing materialized views

2018-08-15 Thread Dian Fay
hi all! I discovered today that the REFRESH MATERIALIZED VIEW documentation doesn't mention that only the owner (or a superuser) may actually perform the refresh operation. This patch adds a note to that effect. Dian Fay diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src