DOC: Updates to spock content #326
Conversation
susan-pgedge
changed the title
📝 WalkthroughWalkthroughThis PR updates Spock documentation: adds many new function docs, revises numerous function signatures and arguments in docs (renames and defaults), expands RETURNS/ARGUMENTS/EXAMPLE sections, and reforms installation and two-node cluster guides to require a psql session before node creation and use fenced code blocks. Changes
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🤖 Fix all issues with AI agents
In `@docs/spock_functions/functions/spock_repset_add_table.md`:
- Around line 7-14: The SYNOPSIS signature for spock.repset_add_table lists
required parameters (set_name, relation, synchronize_data, columns, row_filter,
include_partitions) but the examples call the function with only set_name and
relation; fix by either adding default/optional markers to the SYNOPSIS for
synchronize_data, columns, row_filter, and include_partitions (and document
their defaults) or update every example to call spock.repset_add_table with all
required positional or named arguments (e.g., include synchronize_data, columns,
row_filter, include_partitions), and apply the same change to the other examples
referenced in the file.
In `@docs/spock_functions/functions/spock_repset_alter.md`:
- Around line 27-28: Update the documentation for spock_repset_alter to remove
the contradiction by explicitly specifying which arguments may be NULL to mean
"no change" (e.g., boolean flags like is_enabled, is_streaming, etc.) and which
argument(s) cause the function to return NULL (e.g., set_name if omitted).
Modify the sentences around the current "Any argument left as NULL will retain
its current setting" and "Returns NULL if any argument is NULL" so they read
together: list the nullable boolean parameters that are "no-op when NULL" and
state that a NULL set_name (or other required identifiers) will cause the
function to return NULL; include the symbol names set_name and the specific
boolean parameter names to make locating the behavior clear.
In `@docs/spock_functions/functions/spock_sub_wait_for_sync.md`:
- Around line 3-8: The docs for spock.sub_wait_for_sync are inconsistent: the
header shows spock.sub_wait_for_sync() with no arguments while SYNOPSIS and
ARGUMENTS (and the NULL note) mention subscription_name; pick one canonical
signature and make all sections match it. Update the header, SYNOPSIS, ARGUMENTS
list, and the NULL note in spock_sub_wait_for_sync.md so either every section
shows spock.sub_wait_for_sync() with no parameters or every section shows
spock.sub_wait_for_sync(subscription_name name) (and adjust the NULL note
accordingly); ensure the function name spock.sub_wait_for_sync and the parameter
subscription_name are referenced consistently.
In `@docs/two_node_cluster.md`:
- Line 68: Update the DSN example string so the database name parameter is
explicitly named; in the DSN assignment line starting with "dsn
:='host=<node_2_IP_address> port=<n2_port> =<db_name>');`" replace the stray "
=<db_name>" with " dbname=<db_name>" so the example reads "... port=<n2_port>
dbname=<db_name>");` ensuring the connection string uses the correct "dbname"
parameter.
- Line 96: The doc uses the wrong parameter name: replace the `subscriber_dsn :=
'host=<node_2_IP_address> port=<n2_port> dbname=<db_name>');` assignment with
the correct `provider_dsn` parameter expected by the spock API (see
spock.sub_create / spock_sub_create.md); update any occurrences of
`subscriber_dsn` to `provider_dsn` so the spock.sub_create call supplies the
proper parameter name.
🟡 Minor comments (19)
docs/spock_functions/functions/spock_sub_alter_skiplsn.md-1-5 (1)
1-5:⚠️ Potential issue | 🟡 MinorRemove redundant “NAME” line or make it a proper subheading.
Line 3 repeats the section header and looks like a formatting artifact. Consider dropping it or making it a consistent subheading.docs/spock_functions/functions/spock_sub_alter_skiplsn.md-11-16 (1)
11-16:⚠️ Potential issue | 🟡 MinorInclude NULL behavior in the RETURNS bullets for consistency.
The RETURNS list omits the NULL case that’s described later. Add a bullet for “NULL if any argument is NULL” to keep the API contract scannable.Also applies to: 35-35
docs/spock_functions/functions/spock_sub_show_status.md-29-29 (1)
29-29:⚠️ Potential issue | 🟡 MinorAdd markdown header formatting to section headers.
The section headers "DESCRIPTION" (line 29), "ARGUMENTS" (line 45), and "EXAMPLE" (line 52) are missing markdown formatting (
###), unlike other section headers in this document (lines 1, 5, 9). This breaks the markdown hierarchy and may affect documentation rendering.📝 Proposed fix
-DESCRIPTION +### DESCRIPTION-ARGUMENTS +### ARGUMENTS-EXAMPLE +### EXAMPLEAlso applies to: 45-45, 52-52
docs/spock_functions/functions/spock_sub_show_status.md-17-17 (1)
17-17:⚠️ Potential issue | 🟡 MinorFix inconsistent bullet character.
Line 17 uses an em dash (—) instead of a hyphen (-) like the other bullet points in this list (lines 15, 19, 21, 23, 25, 27). This creates a formatting inconsistency.
📝 Proposed fix
- — Current replication status. + - Current replication status.docs/spock_functions/functions/spock_sync_event.md-7-7 (1)
7-7:⚠️ Potential issue | 🟡 MinorFix spacing inconsistency in function signature.
The SYNOPSIS shows
spock.sync_event ()with a space before the parentheses, while the NAME section (line 3) showsspock.sync_event()without a space. For consistency, remove the space.📝 Proposed fix
-spock.sync_event () +spock.sync_event()docs/spock_functions/functions/spock_node_drop_interface.md-13-13 (1)
13-13:⚠️ Potential issue | 🟡 MinorFix typo in RETURNS section.
Line 13 contains a typo: "false it the interface" should be "false if the interface".
📝 Proposed fix
- - false it the interface did not exist. + - false if the interface did not exist.docs/spock_functions/functions/spock_sub_disable.md-9-13 (1)
9-13:⚠️ Potential issue | 🟡 MinorAdd NULL return case to the RETURNS section.
The DESCRIPTION section (line 33) states "Returns NULL if any argument is NULL," but this return value is not documented in the RETURNS section. For completeness, add the NULL case here so users don't need to read the entire description to understand all possible return values.
📝 Proposed addition
### RETURNS - true if the subscription was successfully disabled. - false if the operation fails. + + - NULL if any argument is NULL.docs/spock_functions/functions/spock_node_create.md-12-12 (1)
12-12:⚠️ Potential issue | 🟡 MinorClarify NULL-return behavior consistency.
Line 12 states the function returns "The OID of the newly created Spock node," but line 30 states "Returns NULL if any argument is NULL." This creates ambiguity about whether the function returns an OID or NULL.
Consider clarifying the RETURNS section to explicitly mention the NULL case, for example:
"The OID of the newly created Spock node, or NULL if any argument is NULL."Also applies to: 30-30
docs/spock_functions/functions/spock_repset_create.md-17-17 (1)
17-17:⚠️ Potential issue | 🟡 MinorClarify OID vs NULL-return behavior.
Line 17 states the function returns "The OID of the newly created replication set," but line 35 states "Returns NULL if any argument is NULL." This is inconsistent.
Consider updating the RETURNS section to: "The OID of the newly created replication set, or NULL if any argument is NULL."
Also applies to: 35-35
docs/spock_functions/functions/spock_repset_remove_seq.md-13-14 (1)
13-14:⚠️ Potential issue | 🟡 MinorClarify boolean vs NULL-return behavior.
Lines 13-14 indicate the function returns boolean (true/false), but line 26 states "Returns NULL if any argument is NULL." This creates ambiguity.
For consistency across the documentation set, consider updating the RETURNS section to explicitly state: "Returns true if the sequence was successfully removed, false if it was not a member, or NULL if any argument is NULL."
Also applies to: 26-26
docs/spock_functions/functions/spock_table_wait_for_sync.md-11-11 (1)
11-11:⚠️ Potential issue | 🟡 MinorResolve void vs NULL-return contradiction.
Line 11 states the function returns "void (returns nothing upon successful completion)," but line 39 states "Returns NULL if any argument is NULL." A void function cannot return NULL in PostgreSQL/SQL semantics.
Consider either:
- Removing line 39 if the function raises an error on NULL arguments, or
- Clarifying that the function behavior is undefined or errors on NULL inputs rather than returning NULL.
Also applies to: 39-39
docs/spock_functions/functions/spock_repset_add_all_tables.md-12-15 (1)
12-15:⚠️ Potential issue | 🟡 MinorClarify boolean vs NULL-return behavior.
Lines 12-15 indicate the function returns boolean (true/false), but line 34 states "Returns NULL if any argument is NULL." This creates ambiguity about the return type behavior.
Consider updating the RETURNS section to explicitly state: "Returns true if all tables were successfully added, false on failure, or NULL if any argument is NULL."
Also applies to: 34-34
docs/spock_functions/functions/spock_sub_drop.md-7-8 (1)
7-8:⚠️ Potential issue | 🟡 MinorDocument the default in the SYNOPSIS.
The DESCRIPTION says
ifexistsdefaults to false, but the SYNOPSIS omitsDEFAULT false. Add the default there to keep the signature consistent.Also applies to: 21-38
docs/spock_functions/functions/spock_repset_add_table.md-99-103 (1)
99-103:⚠️ Potential issue | 🟡 MinorRename
sync_datain the warning text.The warning still uses
sync_data=truebut the parameter is nowsynchronize_data. Update the warning to match the new name.docs/spock_functions/functions/spock_sub_enable.md-7-8 (1)
7-8:⚠️ Potential issue | 🟡 MinorDocument the default in the SYNOPSIS.
immediateis described as default false, but the SYNOPSIS doesn’t showDEFAULT false. Add it for consistency and clarity.Also applies to: 25-44
docs/spock_functions/functions/spock_repset_remove_table.md-12-18 (1)
12-18:⚠️ Potential issue | 🟡 MinorFix section heading formatting for consistency.
RETURNS,DESCRIPTION,ARGUMENTS, andEXAMPLEare missing the###heading marker used elsewhere, and the returns list mixes hyphen and em dash. Standardize headings and list markers to avoid rendering/formatting drift.Also applies to: 33-49
docs/two_node_cluster.md-78-78 (1)
78-78:⚠️ Potential issue | 🟡 MinorRemove extra backtick at end of line.
Line 78 has an extra backtick (
`) at the end that should be removed for proper markdown formatting.📝 Proposed fix
- SELECT spock.repset_add_all_tables('default', ARRAY['public']);` + SELECT spock.repset_add_all_tables('default', ARRAY['public']);docs/spock_functions/functions/spock_repset_add_partition.md-3-3 (1)
3-3:⚠️ Potential issue | 🟡 MinorFix inconsistent function name formatting.
The NAME section uses hyphens (
spock.repset-add-partition), but the actual function name uses underscores (spock.repset_add_partition). This inconsistency could confuse users.📝 Proposed fix
-`spock.repset-add-partition ()` +`spock.repset_add_partition()`docs/spock_functions/functions/spock_repset_add_seq.md-14-15 (1)
14-15:⚠️ Potential issue | 🟡 MinorFix inconsistent bullet punctuation.
Line 14 uses a hyphen (
-) while line 15 uses an em dash (—) for bullet points in the RETURNS section. Use consistent punctuation for better formatting.📝 Proposed fix
- true if the sequence was successfully added to the replication set. - — false if the sequence was already a member of the replication set. + - false if the sequence was already a member of the replication set.
🧹 Nitpick comments (16)
docs/spock_functions/functions/spock_replicate_ddl.md (1)
7-20: Clarify return type and NULL semantics in RETURNS.The RETURNS section mixes “true/false” with “set of booleans” and the NULL rule is only in DESCRIPTION. Consider explicitly stating: single command returns boolean; array returns SETOF boolean; if any argument is NULL then result is NULL (and clarify whether NULL elements in the array yield NULL for that element or NULL for the whole call). This will avoid ambiguity for callers reading only RETURNS.
Also applies to: 39-40
docs/spock_functions/functions/spock_gen_slot_name.md (2)
41-43: Consider showing the expected output in the example.The example demonstrates the function call but doesn't show what result users should expect. Including the output would make the documentation more helpful and complete.
📚 Suggested enhancement to include expected output
### EXAMPLE SELECT spock.spock_gen_slot_name('postgres', 'n1', 'sub_n2_n1'); + +Result: +``` + spock_gen_slot_name +------------------------------ + spock_postgres_n1_sub_n2_n1 +```Note: Adjust the actual output format based on what the function actually returns.
27-40: Optional: Consider adding more context to argument descriptions.While the current argument descriptions are functional, adding brief details about expected values or constraints could improve usability. For example, clarifying whether these names must match existing objects or are arbitrary strings.
docs/spock_functions/functions/spock_sync_event.md (1)
34-34: Consider removing redundant statement.This statement is redundant with the information already provided in the DESCRIPTION section (lines 19-21 and 31-32). The fact that the function inserts a sync marker into the replication stream is clearly documented above.
📝 Proposed change
-This function modifies the replication stream by inserting a sync marker. -docs/spock_functions/functions/spock_node_drop_interface.md (1)
22-31: Remove redundant information.Lines 22-24 and lines 30-31 both mention that the function doesn't modify PostgreSQL server configuration or networking settings. This information is redundant and should be consolidated.
♻️ Proposed consolidation
Consider removing lines 30-31 since the same information is already clearly stated in lines 22-24:
Other nodes that were using this interface to connect will no longer be able to use it. Ensure no active subscriptions are relying on this interface before removing it. -This function writes metadata into the Spock catalogs but does not modify -PostgreSQL server configuration or networking settings. - Returns NULL if any argument is NULL.docs/spock_functions/functions/spock_get_country.md (1)
35-38: Consider showing the expected output in the example.The example demonstrates the function call but would be more helpful if it also showed the expected result, helping users understand what the function returns.
📖 Suggested enhancement for the example
### EXAMPLE SET spock.country = 'US'; SELECT spock.get_country(); + + Expected result: + + get_country + ------------- + US + (1 row)docs/spock_functions/functions/spock_min_proto_version.md (1)
39-41: Consider showing the expected output in the example.Including sample output would help users understand what integer values to expect from this function.
📖 Suggested enhancement for the example
### EXAMPLE SELECT spock.spock_min_proto_version(); + + Expected result: + + spock_min_proto_version + ------------------------- + 1 + (1 row)docs/spock_functions/functions/spock_version.md (1)
27-29: Consider showing the expected output in the example.Displaying a sample version string would help users understand the format returned by this function.
📖 Suggested enhancement for the example
### EXAMPLE SELECT spock.spock_version(); + + Expected result: + + spock_version + --------------- + 3.1.0 + (1 row)docs/spock_functions/functions/spock_version_num.md (1)
31-33: Consider showing the expected output in the example.Since the description explains the XXYYZZ encoding format, showing a concrete example output would reinforce this concept for users.
📖 Suggested enhancement for the example
### EXAMPLE SELECT spock.spock_version_num(); + + Expected result: + + spock_version_num + ------------------- + 30100 + (1 row)docs/spock_functions/functions/spock_max_proto_version.md (1)
37-39: Consider showing the expected output in the example.Including sample output would help users understand what integer values represent protocol versions.
📖 Suggested enhancement for the example
### EXAMPLE SELECT spock.spock_max_proto_version(); + + Expected result: + + spock_max_proto_version + ------------------------- + 2 + (1 row)docs/spock_functions/functions/spock_wait_slot_confirm_lsn.md (1)
48-51: Consider showing the expected output in the example.Even though this function returns void, showing the successful completion would help users understand the expected behavior.
📖 Suggested enhancement for the example
### EXAMPLE SELECT spock.wait_slot_confirm_lsn('spock_local_sync_123456_789abc', '0/3000000'); + + Expected result (after the target LSN is reached): + + wait_slot_confirm_lsn + ----------------------- + + (1 row)docs/spock_functions/functions/spock_sub_alter_interface.md (1)
46-48: Consider showing the expected output in the example.Including the expected result would help users understand what a successful interface change looks like.
📖 Suggested enhancement for the example
### EXAMPLE SELECT spock.sub_alter_interface('sub_n2_n1', 'private_net'); + + Expected result: + + sub_alter_interface + --------------------- + t + (1 row)docs/spock_functions/functions/spock_repset_add_partition.md (1)
7-10: Clarify optional parameters in the SYNOPSIS.The ARGUMENTS section (lines 40-43) and DESCRIPTION (lines 23-24) indicate that the
partitionparameter is optional with a default of NULL, but the SYNOPSIS doesn't reflect this. Consider addingDEFAULT NULLto make the optionality explicit in the signature.📋 Suggested enhancement
spock.repset_add_partition ( parent regclass, - partition regclass, - row_filter text) + partition regclass DEFAULT NULL, + row_filter text DEFAULT NULL)docs/spock_functions/functions/spock_repset_add_seq.md (1)
7-10: Consider showing DEFAULT value in SYNOPSIS.The ARGUMENTS section (line 49) mentions "The default is false" for
synchronize_data, but the SYNOPSIS doesn't include theDEFAULTkeyword. For consistency with other updated functions likespock_repset_add_all_seqs(which showsDEFAULT false), consider adding it.📋 Suggested enhancement
spock.repset_add_seq ( set_name name, relation regclass, - synchronize_data boolean) + synchronize_data boolean DEFAULT false)docs/spock_functions/functions/spock_sub_create.md (2)
53-56: Format replication set names consistently.The accepted replication set names (
default,default_insert_only,ddl_sql) should be formatted with backticks or code formatting for consistency with other parameter values in the documentation.📋 Suggested enhancement
replication_sets An array of replication set names to subscribe to. Accepted values - are default, default_insert_only, ddl_sql. + are `default`, `default_insert_only`, and `ddl_sql`.
7-10: Consider adding DEFAULT keywords to SYNOPSIS for clarity.Similar to the comment on other files, the ARGUMENTS section describes default values for many parameters (
synchronize_structure: false,synchronize_data: false,forward_origins: '{}', etc.), but the SYNOPSIS doesn't show these defaults. While this might be a documentation style choice, adding DEFAULT keywords would improve clarity and match the style used inspock_repset_add_all_seqs.md.
| spock.repset_add_table ( | ||
| set_name name, | ||
| relation regclass, | ||
| synchronize_data boolean, | ||
| columns text[], | ||
| row_filter text, | ||
| include_partitions boolean | ||
| ) |
There was a problem hiding this comment.
Examples don’t match the declared signature.
The SYNOPSIS requires all parameters, but multiple examples call the function with only set_name and relation. Either document defaults in the SYNOPSIS or update examples to include required params (or named-arg defaults).
Also applies to: 79-98
🤖 Prompt for AI Agents
In `@docs/spock_functions/functions/spock_repset_add_table.md` around lines 7 -
14, The SYNOPSIS signature for spock.repset_add_table lists required parameters
(set_name, relation, synchronize_data, columns, row_filter, include_partitions)
but the examples call the function with only set_name and relation; fix by
either adding default/optional markers to the SYNOPSIS for synchronize_data,
columns, row_filter, and include_partitions (and document their defaults) or
update every example to call spock.repset_add_table with all required positional
or named arguments (e.g., include synchronize_data, columns, row_filter,
include_partitions), and apply the same change to the other examples referenced
in the file.
| Any argument left as NULL will retain its current setting. Only the | ||
| specified operation types are modified. |
There was a problem hiding this comment.
Clarify contradictory NULL handling documentation.
Lines 27-28 state "Any argument left as NULL will retain its current setting," but line 33 states "Returns NULL if any argument is NULL." These statements appear contradictory.
If the function is designed to allow NULL values for the boolean parameters to mean "no change," then the return-NULL statement should clarify that only NULL for set_name causes a NULL return. If all parameters being NULL causes a NULL return, then the "retain current setting" behavior needs better explanation.
📝 Suggested clarification
Consider revising to something like:
Any argument left as NULL will retain its current setting. Only the
specified operation types are modified.
This function updates metadata in the Spock catalogs and does not change
PostgreSQL server configuration.
-Returns NULL if any argument is NULL.
+Returns NULL if set_name is NULL.Or if the function truly returns NULL for any NULL argument:
-Any argument left as NULL will retain its current setting. Only the
-specified operation types are modified.
+For each boolean parameter (replicate_insert, replicate_update,
+replicate_delete, replicate_truncate), passing NULL retains the current
+setting. Only non-NULL values modify the behavior.Also applies to: 33-33
🤖 Prompt for AI Agents
In `@docs/spock_functions/functions/spock_repset_alter.md` around lines 27 - 28,
Update the documentation for spock_repset_alter to remove the contradiction by
explicitly specifying which arguments may be NULL to mean "no change" (e.g.,
boolean flags like is_enabled, is_streaming, etc.) and which argument(s) cause
the function to return NULL (e.g., set_name if omitted). Modify the sentences
around the current "Any argument left as NULL will retain its current setting"
and "Returns NULL if any argument is NULL" so they read together: list the
nullable boolean parameters that are "no-op when NULL" and state that a NULL
set_name (or other required identifiers) will cause the function to return NULL;
include the symbol names set_name and the specific boolean parameter names to
make locating the behavior clear.
| spock.sub_wait_for_sync() | ||
|
|
||
| ### SYNOPSIS | ||
|
|
||
| `spock.sub_wait_for_sync()` | ||
|
|
||
| spock.sub_wait_for_sync (subscription_name name) | ||
|
|
There was a problem hiding this comment.
Resolve signature/argument inconsistency.
The NAME shows spock.sub_wait_for_sync() with no args, but the SYNOPSIS/ARGUMENTS still list subscription_name, and the NULL note references it. Align these sections (either remove the arg everywhere or keep it everywhere).
Also applies to: 35-41
🤖 Prompt for AI Agents
In `@docs/spock_functions/functions/spock_sub_wait_for_sync.md` around lines 3 -
8, The docs for spock.sub_wait_for_sync are inconsistent: the header shows
spock.sub_wait_for_sync() with no arguments while SYNOPSIS and ARGUMENTS (and
the NULL note) mention subscription_name; pick one canonical signature and make
all sections match it. Update the header, SYNOPSIS, ARGUMENTS list, and the NULL
note in spock_sub_wait_for_sync.md so either every section shows
spock.sub_wait_for_sync() with no parameters or every section shows
spock.sub_wait_for_sync(subscription_name name) (and adjust the NULL note
accordingly); ensure the function name spock.sub_wait_for_sync and the parameter
subscription_name are referenced consistently.
| A simple test to check that your system is replicating is to connect to the Postgres server on `n1` and add an object (like a table), and then confirm that it is available on `n2`. Similarly, you can create an object on `n2`, and confirm that it has been created on `n1`. | ||
| ```sql | ||
| SELECT spock.node_create (node_name := 'n2', | ||
| dsn :='host=<node_2_IP_address> port=<n2_port> =<db_name>');` |
There was a problem hiding this comment.
Fix missing "dbname" text in DSN connection string.
The connection string is missing the "dbname" parameter name. It currently shows port=<n2_port> =<db_name> but should be port=<n2_port> dbname=<db_name>.
🐛 Proposed fix
SELECT spock.node_create (node_name := 'n2',
- dsn :='host=<node_2_IP_address> port=<n2_port> =<db_name>');`
+ dsn :='host=<node_2_IP_address> port=<n2_port> dbname=<db_name>');📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| dsn :='host=<node_2_IP_address> port=<n2_port> =<db_name>');` | |
| dsn :='host=<node_2_IP_address> port=<n2_port> dbname=<db_name>'); |
🤖 Prompt for AI Agents
In `@docs/two_node_cluster.md` at line 68, Update the DSN example string so the
database name parameter is explicitly named; in the DSN assignment line starting
with "dsn :='host=<node_2_IP_address> port=<n2_port> =<db_name>');`" replace the
stray " =<db_name>" with " dbname=<db_name>" so the example reads "...
port=<n2_port> dbname=<db_name>");` ensuring the connection string uses the
correct "dbname" parameter.
|
|
||
| ```sql | ||
| SELECT spock.sub_create (subscription_name := 'sub_n1_n2', | ||
| subscriber_dsn := 'host=<node_2_IP_address> port=<n2_port> dbname=<db_name>'); |
There was a problem hiding this comment.
Incorrect parameter name: should be provider_dsn, not subscriber_dsn.
The spock.sub_create function uses provider_dsn as the parameter name (as shown in the spock_sub_create.md documentation), not subscriber_dsn. This would cause the command to fail.
🐛 Proposed fix
SELECT spock.sub_create (subscription_name := 'sub_n1_n2',
- subscriber_dsn := 'host=<node_2_IP_address> port=<n2_port> dbname=<db_name>');
+ provider_dsn := 'host=<node_2_IP_address> port=<n2_port> dbname=<db_name>');📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| subscriber_dsn := 'host=<node_2_IP_address> port=<n2_port> dbname=<db_name>'); | |
| SELECT spock.sub_create (subscription_name := 'sub_n1_n2', | |
| provider_dsn := 'host=<node_2_IP_address> port=<n2_port> dbname=<db_name>'); |
🤖 Prompt for AI Agents
In `@docs/two_node_cluster.md` at line 96, The doc uses the wrong parameter name:
replace the `subscriber_dsn := 'host=<node_2_IP_address> port=<n2_port>
dbname=<db_name>');` assignment with the correct `provider_dsn` parameter
expected by the spock API (see spock.sub_create / spock_sub_create.md); update
any occurrences of `subscriber_dsn` to `provider_dsn` so the spock.sub_create
call supplies the proper parameter name.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@mkdocs.yml`:
- Line 86: The nav entry label mistakenly includes the file extension; update
the mkdocs.yml navigation entry that currently reads "spock.gen_slot_name.md():
spock_functions/functions/spock_gen_slot_name.md" to remove ".md" from the label
so it matches other function labels (use "spock.gen_slot_name()") while keeping
the target path "spock_functions/functions/spock_gen_slot_name.md" unchanged.
🧹 Nitpick comments (1)
mkdocs.yml (1)
126-126: Consider adding parentheses for consistency with other function entries.Most function entries include parentheses (e.g.,
spock.version(),spock.sync_event()), but this entry is missing them. Adding()would maintain consistency across the navigation.Proposed fix
- - spock.wait_slot_confirm_lsn: spock_functions/functions/spock_wait_slot_confirm_lsn.md + - spock.wait_slot_confirm_lsn(): spock_functions/functions/spock_wait_slot_confirm_lsn.md
| - Subscription Mgmt Functions: spock_functions/sub_mgmt.md | ||
| - Cluster Mgmt Functions: spock_functions/gen_mgmt.md | ||
| - Function Reference: | ||
| - spock.gen_slot_name.md(): spock_functions/functions/spock_gen_slot_name.md |
There was a problem hiding this comment.
Typo in navigation label: remove .md from the function name.
The label spock.gen_slot_name.md() appears to have .md accidentally included. Other entries use just the function name without the file extension (e.g., spock.get_country()).
Proposed fix
- - spock.gen_slot_name.md(): spock_functions/functions/spock_gen_slot_name.md
+ - spock.gen_slot_name(): spock_functions/functions/spock_gen_slot_name.md📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - spock.gen_slot_name.md(): spock_functions/functions/spock_gen_slot_name.md | |
| - spock.gen_slot_name(): spock_functions/functions/spock_gen_slot_name.md |
🤖 Prompt for AI Agents
In `@mkdocs.yml` at line 86, The nav entry label mistakenly includes the file
extension; update the mkdocs.yml navigation entry that currently reads
"spock.gen_slot_name.md(): spock_functions/functions/spock_gen_slot_name.md" to
remove ".md" from the label so it matches other function labels (use
"spock.gen_slot_name()") while keeping the target path
"spock_functions/functions/spock_gen_slot_name.md" unchanged.
I'll use this branch to manage updates to the documentation; my primary initial focus is on the online help, but I'm finding updates required in other content that will be rolled in as well.