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 1sc9rt-004SQg-Rp for pgsql-general@arkaria.postgresql.org; Thu, 08 Aug 2024 20:36:17 +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 1sc9rs-00GuXh-5q for pgsql-general@arkaria.postgresql.org; Thu, 08 Aug 2024 20:36:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sc9rr-00GuXV-Qu for pgsql-general@lists.postgresql.org; Thu, 08 Aug 2024 20:36:15 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sc9rp-003r12-1Z for pgsql-general@lists.postgresql.org; Thu, 08 Aug 2024 20:36:15 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2f1870c355cso13305021fa.1 for ; Thu, 08 Aug 2024 13:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723149371; x=1723754171; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vsknkADfWLEqrDIwP3GbE5C+U3qOLkVqJHQH0agA1cI=; b=hXyeo3G1eQrMTAKKsTF5Z3E45n5NBw2Bgah0XfowhnCufkBivmDkyfK5bqnic4+fbd krMdEMsjbZuUXOJGxtmrdGRJcvpzCy3BK5h3e9rUnOx2zuQSD6NXa+OpaShzMBnhM5FF QrMlc60JUUebcI2SD1WWVWasGf9Un6FdUNdLsIq//lprckFGMJspAU35IJNYJhA1wXfF GNShD7H5petLI+A7K1OnMRA9scPac1AOGDkFtLk7qgq10vaZ3aQPzMA1fNaP51dUkE1w GnzIn+dPrGNcsP1+YSPY+jz14qTN0bhK+YQKKTlLadQOXqSqzMChOC3TpP2EKQENo20T 8qig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723149371; x=1723754171; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vsknkADfWLEqrDIwP3GbE5C+U3qOLkVqJHQH0agA1cI=; b=U6x2RZRIXIs3ifDNf2i3DneXoWNcBoZZqcKcwoSGpEfx+iSsDUfaF0b+YZBNWp19q+ oUsPvEUjUcp7HSuOZi2T4p5M9bZisFk5jOsIuXGeAsM9I8Kt8gpKmvy8Utn/fEQTLVn5 LPGFv4ffCqKlOUNYLByKamBFPS2xlNo7rQ98+4k6zbXQBAOXhdGuWut2dO/WyYnGe110 xnrOeG876wkG1/vAmy74op2tLgpA1AtSXNhbh4gRe/MQ4M02k8osMEsNUrIVdfDhjVho jwp1P7To0ktpLMsUzmMZFeWrpXyCJDXVcoO7PFH6YcsGzBGvQEK0RrYlAcUFCZOc0Icd Tgbw== X-Forwarded-Encrypted: i=1; AJvYcCViB7cjVWDwlTYG0sGcH2xoSblaQfs9Lga3evWvAZu3Bu4YaQ/igYm887me4xRnRRyZJlJ+DRSYSS1mUeUF8v0b7WxmukUWT2mFyy31a3WzXmkS X-Gm-Message-State: AOJu0YwyAuSGxr7oHU76bc3PVCg878NAIDILkiXVJUBvRNAlMNU5Dj/e bAUXbec2OAde0TPafqzhdr2OO0s9n9Kq1uL6L87098XGreypuGjwxB7wQNKunwDU1xLIQknorQR CI4RPic+2kQ4evG7/2ni1uefL/AQ= X-Google-Smtp-Source: AGHT+IGIbAgR9WP/n43VEnOePbIUAuBDUtXPZWsPVINGpZcHVjN2VYIGKzrT8D5I9+Uj/eODSrbhnpDHRdOZF5kg1/o= X-Received: by 2002:a2e:b5da:0:b0:2ef:2ed2:25b1 with SMTP id 38308e7fff4ca-2f19de3a736mr18529451fa.20.1723149370581; Thu, 08 Aug 2024 13:36:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sabino Mullane Date: Thu, 8 Aug 2024 16:35:32 -0400 Message-ID: Subject: Re: Column type modification in big tables To: Lok P Cc: sud , pgsql-general Content-Type: multipart/alternative; boundary="00000000000020ec63061f31fa2b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000020ec63061f31fa2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 8, 2024 at 2:39=E2=80=AFPM Lok P wrote: > Can anybody suggest any other possible way here. > Sure - how about not changing the column type at all? > one of the columns from varchar(20) to varchar(2) ALTER TABLE foobar ADD CONSTRAINT twocharplease CHECK (length(mycol) <=3D 2= ) NOT VALID; > one of the columns from Number(10,2) to Numeric(8,2) ALTER TABLE foobar ADD CONSTRAINT eightprecision CHECK (mycol <=3D 10^8) NO= T VALID; > two of the columns from varchar(20) to numeric(3) This one is trickier, as we don't know the contents, nor why it is going to numeric(3) - not a terribly useful data type, but let's roll with it and assume the stuff in the varchar is a number of some sort, and that we don't allow nulls: ALTER TABLE foobar ADD CONSTRAINT onekorless CHECK (mycol::numeric(3) is not null) NOT VALID; You probably want to check on the validity of the existing rows: see the docs on VALIDATE CONSTRAINT here: https://www.postgresql.org/docs/current/sql-altertable.html Cheers, Greg --00000000000020ec63061f31fa2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 8, 2024 at 2:39=E2=80=AFPM Lo= k P <loknath.73@gmail.com>= ; wrote:
Can anybod= y suggest any other possible way here.
<= br>
Sure - how about not chang= ing the column type at all?

> one of t= he columns from varchar(20) to varchar(2)

ALTER TABLE foobar ADD CONSTRAINT twocharplease CHECK (length(mycol) = <=3D 2) NOT VALID;
<= br>
> one of the col= umns from Number(10,2) to Numeric(8,2)

ALTER TABLE foobar ADD CONSTRAINT eig= htprecision CHECK (mycol <=3D 10^8) NOT VALID;

= >=C2=A0two of the columns from varcha= r(20) to numeric(3)

This one is trickier, a= s we don't know the contents, nor why it is going to numeric(3) - not a= terribly useful data type, but let's roll with it and assume the stuff= in the varchar is a number of some sort, and that we don't allow nulls= :

ALTER TABLE foobar ADD CONSTRAINT onekorless CHE= CK (mycol::numeric(3) is not null) NOT VALID;

You = probably want to check on the validity of the existing rows: see the docs o= n VALIDATE CONSTRAINT here:


Cheers,=
Greg

--00000000000020ec63061f31fa2b--