Add more context to SendBatch error

[makalaaneesh]

Hi @jackc, this is a follow-up to #872 (comment)

If there is an error while preparing statements in a batch (syntax error for example),

1. the error is thrown as part of the first result regardless of which statement was responsible.
2. the error does not include the culprit SQL statement, which makes it hard to debug.

As fixing 1 is tricky as pointed out in the #872,
This PR just adds a bit of context to the error (similar to #1441 )

Code to test:

	ctx := context.Background()
	conn, err := pgx.Connect(ctx, "postgres://localhost:5432/postgres")
	if err != nil {
		log.Fatal(err)
	}
	defer conn.Close(ctx)

	// Setup: create table outside batch
	conn.Exec(ctx, "DROP TABLE IF EXISTS batch_test")
	conn.Exec(ctx, "CREATE TABLE batch_test (id SERIAL PRIMARY KEY, name TEXT, value INT)")

	// Batch with 3 statements
	batch := &pgx.Batch{}
	batch.Queue("INSERT INTO batch_test (name, value) VALUES ($1, $2)", "item1", 100)
	batch.Queue("INSERT INTO batch_test (name, value) VALS ($1, $2)", "item2", 200) // SYNTAX ERROR
	batch.Queue("INSERT INTO batch_test (name, value) VALUES ($1, $2)", "item3", 300)

	br := conn.SendBatch(ctx, batch)
	for i := 0; i < 3; i++ {
		if _, err := br.Exec(); err != nil {
			panic(fmt.Sprintf("statement %d failed: %v", i+1, err))
		}
	}
	br.Close()

	fmt.Println("Batch executed successfully")

Before:
panic: statement 1 failed: ERROR: syntax error at or near "VALS" (SQLSTATE 42601)

After:
panic: statement 1 failed: failed to prepare statement: INSERT INTO batch_test (name, value) VALS ($1, $2): ERROR: syntax error at or near "VALS" (SQLSTATE 42601)

[jackc]

I'm wary about including the entire SQL string in an error. We've had complaints before about error messages potentially leaking sensitive information into logs. I'd prefer to avoid adding any new leak vectors. Also, SQL text can be very large and I'm not sure we want to put the whole thing in error text.

I am still interested in improving this situation though. The "failed to prepare statement" part of the message is interesting. That, or something like it that made clear that the error occurred while preparing the batch is a good idea.

[makalaaneesh]

That's fair.

How about returning a specific error struct (something like ErrPreprocessingBatch )?

• It would contain the exact SQL of the batch, more context on which step failed (prepare, in this case), etc
• Its string representation would NOT contain the SQL.

That way,

• by default, we improve the error reporting by making it clear that the error occurred while pre-processing the batch. No SQL in the string representation, so no leaking sensitive info by default.
• if the user wants to get the specific problematic SQL, they can inspect the error struct.

What do you think?

[jackc]

That sounds like a reasonable approach.