Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzh0b-0004a5-9W for pgsql-admin@arkaria.postgresql.org; Fri, 10 Jun 2022 15:57:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nzh0Z-0008Mk-Oc for pgsql-admin@arkaria.postgresql.org; Fri, 10 Jun 2022 15:57:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzh0Z-0008Ma-AV for pgsql-admin@lists.postgresql.org; Fri, 10 Jun 2022 15:57:11 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nzh0W-0003Jy-6m for pgsql-admin@postgresql.org; Fri, 10 Jun 2022 15:57:10 +0000 Received: by mail-ed1-x52d.google.com with SMTP id v19so35858635edd.4 for ; Fri, 10 Jun 2022 08:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=AVp8/Qi5lyIOHnvOeLpRnWDiwzq9meIAk2otNo7G1+g=; b=tmCyFbsSEPcPF5rZEblWNveUBfR8Nua+fKMoG+uh6Xzttk2iN/7/tEdazE6h65vdHk ouTf67z9ZwVc0W1A7UpA4mUsWa4cgoBYnUlrzMxZxsaezHHBGM9/fxW30M0ye49dagj1 nbg0UVdAjz10BOJl476ZfjHuGq8g/GkHdFoR9xwTfkfPs5l55KFMUkF5a1HDCuvCauK1 jcMp9hMkzzPBgy/SK64K+QAGzfFDEAkkAgIUdu1/O6feBNKhmRGe4lJo62Wus9R1rTrm R628j1SvrNF4UePfEvKp1HF9WblOFQRuA/8B7rigZxE3aT4Wdb77OgW7TvgblX6gwY3x mr8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=AVp8/Qi5lyIOHnvOeLpRnWDiwzq9meIAk2otNo7G1+g=; b=3cC72Kv8DM2QVS1dvWpvmVqnEZt6/yzlcdJyyQsTMAm5Dehdlp5pSF9dX/XBICt4pF jibIZkojiRq1nfHlPpFGoQ/K6ixtFKClMWKMV4ihTHv2/kxcPMkzxab3L3tVCOPM5tXL 79rR9RA1BdGtqsyns7Yqz9s3YJvPpJfTxC5Io5xe+Mg+cyVo5qAz4xHoBTlXx89NWJwC u4OVVymNtsN9jZjOF6JLjK8XRzB4U0RElxBrFpjOiFq4DGMs4ubMCdi6N4xw7r3EenSR JW9w6QuotC134O9napHlYVMe8EJ4DGbZIA8ojpP27304MTe6yQWxrFhHgrfUNK/PjVfd AwjA== X-Gm-Message-State: AOAM533w40TiCGKwoomPt2gj9efLrNtTAsNbaXIC+e68BmZgpVB8usCx he/1yk5yqzrZsy10RnJF2bYK+ci3+cMJ6g== X-Google-Smtp-Source: ABdhPJxy+HI6g8WftIa1azt7PLwAvUSW29mvRl6mZqnqbefGaqH7lmWTK9Of4C2qI31yVZ9kSmBbCQ== X-Received: by 2002:a05:6402:500b:b0:431:78d0:bf9d with SMTP id p11-20020a056402500b00b0043178d0bf9dmr24636044eda.184.1654876625735; Fri, 10 Jun 2022 08:57:05 -0700 (PDT) Received: from localhost.localdomain (178-190-180-147.adsl.highway.telekom.at. [178.190.180.147]) by smtp.gmail.com with ESMTPSA id ck11-20020a0564021c0b00b0042de3d661d2sm16756467edb.1.2022.06.10.08.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 08:57:05 -0700 (PDT) Message-ID: Subject: Re: ERROR: type "my_user_type" does not exist on REFRESH MATERIALIZED VIEW From: Laurenz Albe To: Pascal CROZET , pgsql-admin Date: Fri, 10 Jun 2022 17:57:04 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2022-06-09 at 19:52 +0000, Pascal CROZET wrote: > Hi DBA's (PG 12.10 on Ubuntu 20.04) > > In a restoration from a full plain text database ( xzcat my_database.sql.xz | psql ), I've this issue at the end. > > REFRESH MATERIALIZED VIEW > ERROR:  type "row_reporting_p" does not exist > LINE 3:  _row row_reporting_p; >               ^ > QUERY:   > DECLARE > _row row_reporting_p; > > BEGIN > >     -- my code > > END > > CONTEXT:  compilation of PL/pgSQL function "get_row_reporting_new" near line 3 > ERROR:  type "row_reporting_p" does not exist > LINE 23:     _row row_reporting_p; > > Of course, the user type is present and well restored before, 'cause the last SQL commands > from the file are forREFRESH MATERIALZED VIEW vm_my_materialized_view; > > When I refresh the materialized view manually, from psql, the refresh is well. > This issue is only present on databases using user type. On other databases restoration, > not using user type, I haven't this isssue. > > Is it a PostGreSql bug ? Thanks I would have to see the dump to be certain, but my guess is that you need to make the function independent from the current setting of "search_path" by schema-qualifying the data type: DECLARE _row my_schema.row_reporting_p; Yours, Laurenz Albe