On 21/04/15 22:36, Andres Freund wrote:
> On 2015-04-21 16:26:08 -0400, Robert Haas wrote:
>> On Tue, Apr 21, 2015 at 8:08 AM, Andres Freund <andres@anarazel.de> wrote:
>>> I've now named the functions:
>>>
>>> * pg_replication_origin_create
>>> * pg_replication_origin_drop
>>> * pg_replication_origin_get (map from name to id)
>>> * pg_replication_progress_setup_origin : configure session to replicate
>>> from a specific origin
>>> * pg_replication_progress_reset_origin
>>> * pg_replication_progress_setup_tx_details : configure per transaction
>>> details (LSN and timestamp currently)
>>> * pg_replication_progress_is_replaying : Is a origin configured for the session
>>> * pg_replication_progress_advance : "manually" set the replication
>>> progress to a value. Primarily useful for copying values from other
>>> systems and such.
>>> * pg_replication_progress_get : How far did replay progress for a
>>> certain origin
>>> * pg_get_replication_progress : SRF returning the replay progress for
>>> all origin.
>>>
>>> Any comments?
>>
>> Why are we using functions for this rather than DDL?
>
> Unless I miss something the only two we really could use ddl for is
> pg_replication_origin_create/pg_replication_origin_drop. We could use
> DDL for them if we really want, but I'm not really seeing the advantage.
>
I think the only value of having DDL for this would be consistency
(catalog objects are created via DDL) as it looks like something that
will be called only by extensions and not users during normal operation.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
