Describe the bug
Both functions rely on Postgres's COPY command, ag_load_labels.c and ag_load_edges.c share an identical create_copy_options() that only passes two options to BeginCopyFrom (header and format, everything else is default from Postgres).
load_labels_from_file with a pipe-delimited multi-column label CSV file silently corrupts data (correctly since default is comma). The entire line is read as a single field, column names get merged with values into one token, and the result lands in properties as garbage with no error:
id | properties
----------+---------------------------------------------
... | {"__id__": 1, "id|islocatedin_city": "1|5"}load_edges_from_file with a pipe-delimited file crashes the server. The 4-column edge format requires start_id, start_vertex_type, end_id, end_vertex_type as separate fields. A quick lookup on it shows that with no comma splitting, fields[1] through fields[3] are null, process_edge_row calls trim_whitespace(fields[1]) on a bad pointer, and the server segfaults.
The documentation mentions no delimiter requirement. The example files use comma but this is never stated as a constraint. The header row is handled manually in the loop rather than by COPY itself (HEADER false), so the parsing feels custom, which makes it even less obvious that COPY's delimiter default is silently in effect underneath.
How are you accessing AGE (Command line, driver, etc.)?
What is the command that caused the error?
SELECT load_labels_from_file('graph', 'Label', '/derived/Label.csv'); -- No error, just incorrect parsing.
SELECT load_edges_from_file('graph', 'SomeEdge', '/derived/SomeEdge.csv'); -- This segfaults026-06-29 19:25:56.972 GMT [1] LOG: client backend (PID 64) was terminated by signal 11: Segmentation fault
2026-06-29 19:25:56.972 GMT [1] DETAIL: Failed process was running: SELECT load_edges_from_file('graph', 'SomeEdge', '/derived/SomeEdge.csv');
2026-06-29 19:25:56.972 GMT [1] LOG: terminating any other active server processes
Expected behavior
Depends really, either have a delimiter option just like postgres COPY command options or clarify in documentation + correct error if comma only (instead of segfaulting).
Environment (please complete the following information):
Describe the bug
Both functions rely on Postgres's COPY command,
ag_load_labels.candag_load_edges.cshare an identicalcreate_copy_options()that only passes two options toBeginCopyFrom(header and format, everything else is default from Postgres).load_labels_from_filewith a pipe-delimited multi-column label CSV file silently corrupts data (correctly since default is comma). The entire line is read as a single field, column names get merged with values into one token, and the result lands in properties as garbage with no error:load_edges_from_filewith a pipe-delimited file crashes the server. The 4-column edge format requiresstart_id, start_vertex_type, end_id, end_vertex_typeas separate fields. A quick lookup on it shows that with no comma splitting, fields[1] through fields[3] are null,process_edge_rowcallstrim_whitespace(fields[1])on a bad pointer, and the server segfaults.The documentation mentions no delimiter requirement. The example files use comma but this is never stated as a constraint. The header row is handled manually in the loop rather than by COPY itself
(HEADER false), so the parsing feels custom, which makes it even less obvious that COPY's delimiter default is silently in effect underneath.How are you accessing AGE (Command line, driver, etc.)?
What is the command that caused the error?
Expected behavior
Depends really, either have a delimiter option just like postgres COPY command options or clarify in documentation + correct error if comma only (instead of segfaulting).
Environment (please complete the following information):