Someone pointed out this morning that we still have this in our docs:
"It is advantageous if the WAL is located on a different disk from the main
database files. This can be achieved by moving the pg_wal directory to
another location (while the server is shut down, of course) and creating a
symbol
On Mon, Mar 18, 2024 at 11:58 AM Laurenz Albe
wrote:
> I think it is still a good idea to put data files and WAL on different file
> systems. Perhaps not so much with the intention of distributing I/O across
> different disks, but to prevent the data files from filling the WAL disk.
>
Cannot sa
While looking over the event trigger docs, I noticed that the sample code
references the two special table rewrite functions (returning oid and
reason for the rewrite), but the event trigger page itself does not mention
them, although it does mention the functions available for the other types
of e
On Mon, Sep 2, 2024 at 9:57 PM Laurenz Albe
wrote:
> I think that it would be better to add a reference to
>
> https://www.postgresql.org/docs/16/functions-event-triggers.html#FUNCTIONS-EVENT-TRIGGER-TABLE-REWRITE
> than to repeat that information.
>
> If you feel that "The exact meaning of the c
How about something like this? I realize the other functions in that
section are not linked, but they all seem pretty self-explanatory compared
to the mysterious int return value of the linked one.
Cheers,
Greg
0002-Document-the-event-trigger-table-rewrite-functions.patch
Description: Binary dat
On Wed, Sep 11, 2024 at 2:00 AM Michael Paquier wrote:
> Putting the documentation change aside for a bit, could it be better
> to redesign this function and return a text value rather than an
> integer? We could directly return the names, minus "AT_REWRITE_", for
> instance.
>
I dunno - so wo
On Wed, Sep 11, 2024 at 11:17 PM Michael Paquier
wrote:
> If multiple are set, let's just make it text[], then.
>
Hmmm...I guess it's better than an integer, in some ways, but I'm still a
weak -1.
> That would be a step backwards for anyone possibly using that integer
> > programatically to (fo
On Thu, Nov 14, 2024 at 3:32 AM "Сергей П (SergeiDos)" <
podrezov.ser...@gmail.com> wrote:
> It would be logical if we formed the rules for our database developers
> identical to the internal automatic rules for forming names in the
> database, so that developers who choose the path of automatic n
On Wed, Dec 4, 2024 at 8:03 AM PG Doc comments form
wrote:
> I am interpreting this to mean that if I as user A receive a notification
> to
> a channel that I have set up, then user B and user C will also see this
> notification, irrespective of their various permissions. Am I understanding
> thi
On Fri, Dec 20, 2024 at 5:53 AM wrote:
> Well, as I said, that's a *text* value with a *byte* limit. The
> documentation should definitely mention something like *"with the default
> database encoding"*.
>
I'm not sure why you think adding such wordage is needed. Bytes is bytes.
Your application
Your BETWEEN statement has X AND Y inside of parenthesis. No parenthesis
are needed, the format is:
BETWEEN X AND Y
not
BETWEEN (X AND Y)
See:
https://www.postgresql.org/docs/current/functions-comparison.html
Postgres is complaining about the EXCEPT because it is waiting for the next
item in
11 matches
Mail list logo
