Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tIWxL-00EuOT-0I for pgsql-general@arkaria.postgresql.org; Tue, 03 Dec 2024 17:45:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tIWwK-00BXXO-5t for pgsql-general@arkaria.postgresql.org; Tue, 03 Dec 2024 17:44:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tIWwJ-00BXXG-Pt for pgsql-general@lists.postgresql.org; Tue, 03 Dec 2024 17:44:01 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tIWwI-000rWa-Ig for pgsql-general@lists.postgresql.org; Tue, 03 Dec 2024 17:43:59 +0000 Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2ee397a82f6so4240909a91.2 for ; Tue, 03 Dec 2024 09:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733247838; x=1733852638; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=KElOgE2fJTylCDhbS3OgMIho/pq+QnJ26xetz3IT9mc=; b=SX/RdUsye7jw0cxL3JZK9gQ2ja1adjFpjpxZpSjV4aqGFiT83YG7UIS2CKLBEHkyXc g7hQRIgzulrhkeNX4vgG7y8dtrBWSrTnoU8ftUUvINJvsoW5A1q4+5v9mWynVooWi4OD 1Qcb2SxZ56M+jrxeGqxzgbXzbVZBcD9DbKdnevH99tWg2zpSZBwI6uVkfsRcw8/7l+s0 UgZCeqPrb9l1JFXitnK6Rd05o0fQQTJEdEPanDsFbLLJhRwbJo7bITNcMjoIyAegarvr kMYKGBz9C1C5jUtBmkIhq6fbaRMp8zl8WIPpIsRhIOtZEWO5fZdtLVvye/m2/sZq4sAe 1dDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733247838; x=1733852638; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KElOgE2fJTylCDhbS3OgMIho/pq+QnJ26xetz3IT9mc=; b=hQjui76R9BNEdaBqh348ajoDXZ2nB7LxaJs/m/uGoXoBUzcQZQoM0rAIaf6MxGzWx2 zt7cDr2D83OzU3W8DQWz7RqsfW8e0yn2SQ/qLaeZgIWpXrzpA83SFvdoobsySuG8YkAS t5jWPM4W1NJnAYoIMdB+0nLPDkUpF4il49cndKVtT7f95nOK+s69CFjH+4tANFFezIKi yYaFAPtDXaYGpUN1B7GMybIqtNWH7DB3wFZIVWx5qUe4q478T2A0WSEPKhSRLU0xakl6 2bL7wYZ5/PP/eerOvJMFq58kCue9Yh4awS7tRvHNswKjcEBWnxkQW4QTZcdkuiH6xhLQ qHzA== X-Forwarded-Encrypted: i=1; AJvYcCWhHBzxliL1PlF/8jJhEyouUy/PWXieLEsW55R4ulVzEWZ9SAVuCZDmfCsBz3Sv9H/A44tqi3qOR8uQrTXq@lists.postgresql.org X-Gm-Message-State: AOJu0Yz/rV0UaP3o3lZDK+zF18aRVexH+vMp53ee6T1lRigXs+STn5F0 Cmvc/dzLRRRAOd66wHIGVBIpjflH9BEtpJiv6h91T54uNm7oDUP+Jt5pLnd+zvSVhG9OIcBw8Ou 5y083PylJgrCLQcv2Dq67oHcESwazMwuK X-Gm-Gg: ASbGncuu0TRTQZIf+gC6XVuS2+CwLesWyIOH896R6iWjnpjHtBGGa205QkfCm/AjnPg QaBbyc10eLnJkOEWj5ayWGN4+9N7G+G5K X-Google-Smtp-Source: AGHT+IEQkXnN5pugtcNhRCWBtAUY5e289dfw788w8c1egV0CwKRMunP0Q7Rne1cNsXX4Rw9jS/9gCs/m2sLpYvaoN0I= X-Received: by 2002:a17:90b:2e83:b0:2ee:c059:7de3 with SMTP id 98e67ed59e1d1-2ef012101eamr4041619a91.18.1733247837430; Tue, 03 Dec 2024 09:43:57 -0800 (PST) MIME-Version: 1.0 From: Sasmit Utkarsh Date: Tue, 3 Dec 2024 23:13:46 +0530 Message-ID: Subject: Best Practices for Managing Schema Changes Dynamically with libpq To: pgsql-general , pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000a86db10628613544" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a86db10628613544 Content-Type: text/plain; charset="UTF-8" Dear PostgreSQL Community Team, I am working on a project that uses libpq along with C language to interact with PostgreSQL, and we face challenges with managing schema changes dynamically in production while avoiding downtime. Specifically, we need guidance on handling table structure changes/additions without tightly coupling these changes to application updates. *Current Approach:* Schema changes are deployed first, followed by application updates to align with the new structure. *Challenges:* Ensuring application stability during the transitional phase when the schema and code are not fully in sync. Handling table structure changes (e.g., adding new columns) dynamically without requiring immediate code changes. *Questions:* Are there recommended best practices for managing such schema changes with libpq? How can we efficiently handle table additions/updates while keeping the application and database in sync dynamically? I would appreciate any guidance, patterns, or examples that can help us implement a robust solution. Thank you for your time and support! Regards, Sasmit Utkarsh +91-7674022625 --000000000000a86db10628613544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear PostgreSQL Community Team,

I am working o= n a project that uses libpq along with C language to interact with PostgreS= QL, and we face challenges with managing schema changes dynamically in prod= uction while avoiding downtime. Specifically, we need guidance on handling = table structure changes/additions without tightly coupling these changes to= application updates.

Current Approach:
Schema changes are= deployed first, followed by application updates to align with the new stru= cture.

Challenges:
Ensuring application stability during t= he transitional phase when the schema and code are not fully in sync.
Ha= ndling table structure changes (e.g., adding new columns) dynamically witho= ut requiring immediate code changes.

Questions:
Are there = recommended best practices for managing such schema changes with libpq?
= How can we efficiently handle table additions/updates while keeping the app= lication and database in sync dynamically?

I would appreciate any gu= idance, patterns, or examples that can help us implement a robust solution.=

Thank you for your time and support!

Regards,
Sasmit Utkarsh
+91-767= 4022625
--000000000000a86db10628613544--