Skip to content

Conversation

@miladev95
Copy link
Contributor

  • Do only one thing
  • Non breaking API changes
  • Tested

This PR covers #7629 feature request.

What did this pull request do?

Add PrepareStmtAutoSave Support for PostgreSQL

Overview

Introduces new PrepareStmtAutoSave configuration option to enable PostgreSQL's autosave_prepared_statements parameter. This helps prevent prepared statement cache invalidation errors when schema changes occur during runtime.

Problem Statement

When using prepared statements with GORM:

  • PostgreSQL caches prepared statements for performance
  • If the schema changes (e.g., column added/removed), cached statements become invalid
  • This causes execution errors like "column does not exist"
  • Requires manual cache clearing or connection reconnect

Solution

Enable PostgreSQL's autosave_prepared_statements parameter to automatically invalidate cached statements when schema changes, preventing execution errors.

Changes

  • New Config Field: PrepareStmtAutoSave *bool

    • nil = disabled (default, no configuration)
    • true = enable autosave
    • false = explicitly disable autosave
  • New Method: configureAutoSave(ctx context.Context) error

    • Executes SET autosave_prepared_statements = true/false on PostgreSQL connection
    • Called during database initialization if PrepareStmt is enabled
    • Only applicable to PostgreSQL
  • Updated: Open() function to call configureAutoSave() during initialization

Usage Example

// Enable prepared statements with autosave
trueVal := true
db, err := gorm.Open(
    postgres.Open(dsn),
    &gorm.Config{
        PrepareStmt: true,ave: &trueVal,
        PrepareStmtAutoS
    },
)

// Disable autosave
falseVal := false
db, err := gorm.Open(
    postgres.Open(dsn),
    &gorm.Config{
        PrepareStmt: true,
        PrepareStmtAutoSave: &falseVal,
    },
)

// Not set (default - no autosave configuration)
db, err := gorm.Open(
    postgres.Open(dsn),
    &gorm.Config{
        PrepareStmt: true,
    },
)

…d_statements

- Add PrepareStmtAutoSave configuration field to Config struct (*bool type)
- Support nil (disabled), true, and false values
- PostgreSQL will automatically invalidate cached prepared statements on schema changes
- Only applicable for PostgreSQL databases

The autosave_prepared_statements parameter helps prevent errors when schema changes
occur while prepared statements are cached. When enabled, PostgreSQL invalidates the
cached statements automatically instead of causing statement execution errors.
@propel-code-bot
Copy link
Contributor

propel-code-bot bot commented Nov 4, 2025

Add PrepareStmtAutoSave option for PostgreSQL prepared-statement autosave

Introduces a tri-state PrepareStmtAutoSave *bool field to gorm.Config and wires it into gorm.Open() through a new helper configureAutoSave(). When the flag is non-nil and the current dialect is PostgreSQL, GORM issues SET autosave_prepared_statements = <true|false> once during initialization, reducing runtime errors caused by invalidated cached prepared statements after DDL changes.
The change is self-contained to gorm.go, adds ~34 LoC, does not modify existing behaviour for other dialects, and keeps API backward-compatible.

Key Changes

• Added PrepareStmtAutoSave *bool to Config with detailed comments
• Updated Open() to invoke configureAutoSave() when PrepareStmtAutoSave is non-nil
• Implemented DB.configureAutoSave(ctx) with dialect guard, warning log, and SET autosave_prepared_statements execution
• Extended docs/comments for the new option

Affected Areas

gorm.Config struct definition
Open() initialization flow
DB helper methods (new configureAutoSave())

This summary was automatically generated by @propel-code-bot

}
}

if err == nil && config.PrepareStmtAutoSave != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[BestPractice]

The configureAutoSave method is called only when PrepareStmtAutoSave is non-nil, but there's no validation that PrepareStmt is enabled. The autosave_prepared_statements parameter only applies when prepared statements are being used. If PrepareStmt is false but PrepareStmtAutoSave is set, this configuration will have no effect and may be confusing.

Suggested change
if err == nil && config.PrepareStmtAutoSave != nil {
if err == nil && config.PrepareStmt && config.PrepareStmtAutoSave != nil {
err = db.configureAutoSave(context.Background())
}

Committable suggestion

Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Context for Agents
[**BestPractice**]

The `configureAutoSave` method is called only when `PrepareStmtAutoSave` is non-nil, but there's no validation that `PrepareStmt` is enabled. The `autosave_prepared_statements` parameter only applies when prepared statements are being used. If `PrepareStmt` is false but `PrepareStmtAutoSave` is set, this configuration will have no effect and may be confusing.

```suggestion
if err == nil && config.PrepareStmt && config.PrepareStmtAutoSave != nil {
	err = db.configureAutoSave(context.Background())
}
```

⚡ **Committable suggestion**

Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

File: gorm.go
Line: 247

@propel-code-bot propel-code-bot bot changed the title feat: add PrepareStmtAutoSave support for PostgreSQL autosave_prepare… Add PrepareStmtAutoSave option to enable PostgreSQL autosave_prepared_statements Nov 4, 2025

// Execute SET command on the connection
sql := fmt.Sprintf("SET autosave_prepared_statements = %v", value)
if err := db.Exec(sql).Error; err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[BestPractice]

Connection-level vs session-level configuration: Using db.Exec() to set PostgreSQL parameters only affects the current connection/session. If GORM uses a connection pool, different connections may not have this setting applied, leading to inconsistent behavior.

Consider setting this parameter in the PostgreSQL connection string instead, or document that this setting only applies to the current session.

Context for Agents
[**BestPractice**]

Connection-level vs session-level configuration: Using `db.Exec()` to set PostgreSQL parameters only affects the current connection/session. If GORM uses a connection pool, different connections may not have this setting applied, leading to inconsistent behavior.

Consider setting this parameter in the PostgreSQL connection string instead, or document that this setting only applies to the current session.

File: gorm.go
Line: 574

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant