pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Subject: Re: Statistics Import and Export
Date: Wed, 03 Apr 2024 16:02:47 -0400
Message-ID: <261289.1712174567@sss.pgh.pa.us> (raw )
In-Reply-To: <CADkLM=egYXeOGF2=AxOYej-=VjTNb3wcyEPqKd7_0CLxfKppjw@mail.gmail.com >
References: <Zei1xMGH8SJS9yoc@tamriel.snowman.net >
<54f190b6c757da2a33cce811949e9dd9601fcba7.camel@j-davis.com >
<1632327b74a734f8c434eb75e824160d2b06a697.camel@j-davis.com >
<CADkLM=dOUfTtpmE70mx5SmdEs11hic61G-wPa45pB1iC3NRABg@mail.gmail.com >
<16412b8b7ae443cb7470006beff3011927048860.camel@j-davis.com >
<CADkLM=cq1n2wbxhV23pOeUKReBPZxZyELDsDJ3VAxkYBSVAe0g@mail.gmail.com >
<CADkLM=d_WYoFq75eoNHso+9EFDi=Q2BtCmxQYMjrgLL4=v5dxw@mail.gmail.com >
<1b1bd1ec39ab3de09a17bf7b241021067e5bd63c.camel@j-davis.com >
<CADkLM=eJXPQD=pWwwm+4Y48haiMmznB8dCECNMrwr59niY8ESw@mail.gmail.com >
<2bce855db8259c5672a09f863a307ca07b967b68.camel@j-davis.com >
<CADkLM=dw=fkvPRmOw74UDYnLzXwkDyMSY1k2jsU5=xXBAj7Mpw@mail.gmail.com >
<5e94c358caedf2a231dd71624c3578db7227a265.camel@j-davis.com >
<CADkLM=dztWa9shWHyq=+rS9KvbZQ2v54tnOcYT+g8psf0B7w_A@mail.gmail.com >
<CADkLM=fFwkd7VbO4SPCyX-2f-fyGraka5J+5fcp1QMrCefu68Q@mail.gmail.com >
<CADkLM=cioQmOFh98qQmqVEkVPjLYszEhZtNtUbmmNAdHOSr3WQ@mail.gmail.com >
<CADkLM=f9FOu9Z2GT1c! btRaffDvtXyUOuv2HMVw0=phYe2T2D9w@mail.gmail.com >
<CABUevEz1gLOkWSh_Vd9LQh-JM4i=Mu7PVT9ffc77TmH0Zh3TzA@mail.gmail.com >
<CADkLM=dTY5bkMB4WO0aTYEOP=re0_QjWfYyPd-A5-BvEQdn9cA@mail.gmail.com >
<790773.1711910899@sss.pgh.pa.us >
<8bc6ffe1e5abeac0fdde1a83d95409f0463af013.camel@j-davis.com >
<1141637.1711994977@sss.pgh.pa.us >
<CADkLM=f+29F1csUZ=7ic0dPwQgV2C1NJycb8A-rk8GQkxC=Jwg@mail.gmail.com >
<1215956.1711999455@sss.pgh.pa.us >
<CADkLM=crgW-p8EpR2QLnmRC7axFXeW-2QbKSb4jpuwoCaYqDEA@mail.gmail.com >
<1321788.1712005745@sss.pgh.pa.us >
<CADkLM=fpbw6EC3hW4N-RxwxMcNBH8F+M6atyiOapL-PkgfWZCg@mail.gmail.com >
<1328631.1712008078@sss.pgh.pa.us >
<CADkLM=daPdFB8V0tgFxK-dLowFsAEzWRWJHyxij7BG3kBjcouA@mail.gmail.com >
<7d37175cd5b56ab04940ed6b5a72354ae90783ee.camel@j-davis.com >
<CADkLM=dFrHKkMeBKwFJz4FsC0vTDmjoc3iy-+cfL=XKBAY5UjA@mail.gmail.com >
<1841621.1712093467@sss.pgh.pa.us >
<06286ee47fa4b06b6e7f08da21958d7e35525ed4.camel@j-davis.com >
<CADkLM=fXi_3OCTZ+gjKiJLZNHp_hpuBD1cf8QMsWo41bw1kMdg@mail.gmail.! com >
<CADkLM=diTMqw-9mgBRdHCeh1TgVLgFM4sR-b9VzO=8mDn3VWqw@mail.gmail.com >
<149855.1712164687@sss.pgh.pa.us >
<CADkLM=egYXeOGF2=AxOYej-=VjTNb3wcyEPqKd7_0CLxfKppjw@mail.gmail.com >
Corey Huinker <corey.huinker@gmail.com> writes:
>> As far as that goes, it shouldn't be that hard to deal with, at least
>> not for "soft" errors which hopefully cover most input-function
>> failures these days. You should be invoking array_in via
>> InputFunctionCallSafe and passing a suitably-set-up ErrorSaveContext.
>> (Look at pg_input_error_info() for useful precedent.)
> Ah, my understanding may be out of date. I was under the impression that
> that mechanism relied on the the cooperation of the per-element input
> function, so even if we got all the builtin datatypes to play nice with
> *Safe(), we were always going to be at risk with a user-defined input
> function.
That's correct, but it's silly not to do what we can. Also, I imagine
that there is going to be high evolutionary pressure on UDTs to
support soft error mode for COPY, so over time the problem will
decrease --- as long as we invoke the soft error mode.
> 1. NULL input => Return NULL. (because strict).
> 2. Actual error (permissions, cache lookup not found, etc) => Raise ERROR
> (thus ruining binary upgrade)
> 3. Call values are so bad (examples: attname not found, required stat
> missing) that nothing can recover => WARN, return FALSE.
> 4. At least one stakind-stat is wonky (impossible for datatype, missing
> stat pair, wrong type on input parameter), but that's the worst of it => 1
> to N WARNs, write stats that do make sense, return TRUE.
> 5. Hunky-dory. => No warns. Write all stats. return TRUE.
> Which of those seem like good ereturn candidates to you?
I'm good with all those behaviors. On reflection, the design I was
vaguely imagining wouldn't cope with case 4 (multiple WARNs per call)
so never mind that.
regards, tom lane
view thread (543+ messages) latest in thread
Message-ID: <261289.1712174567@sss.pgh.pa.us>
Permalink: ../261289.1712174567@sss.pgh.pa.us/
Also on: postgresql.org/message-id/261289.1712174567@sss.pgh.pa.us
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, corey.huinker@gmail.com, pgsql@j-davis.com, magnus@hagander.net, sfrost@snowman.net, ashutosh.bapat.oss@gmail.com, boekewurm+postgres@gmail.com, smithpb2250@gmail.com, pgsql-hackers@lists.postgresql.org, tomas.vondra@enterprisedb.com
Subject: Re: Statistics Import and Export
In-Reply-To: <261289.1712174567@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox