public inbox for [email protected]  
help / color / mirror / Atom feed
From: Julien Rouhaud <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: RĂ©mi Lapeyre <[email protected]>
Cc: Zhihong Yu <[email protected]>
Cc: David Steele <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: vignesh C <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Daniel Verite <[email protected]>
Subject: Re: Add header support to text format and matching feature
Date: Mon, 13 Jun 2022 10:32:13 +0800
Message-ID: <20220613023213.bj7qjnplvgfmx522@jrouhaud> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAM-w4HPkjYQGPm0-zx3XZHnQ_+B8AyWuCn_LyTeX7sNJCv4x8A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<20220607154744.vvmitnqhyxrne5ms@jrouhaud>
	<[email protected]>

Hi,

On Sun, Jun 12, 2022 at 09:36:13AM -0400, Andrew Dunstan wrote:
> 
> On 2022-06-07 Tu 11:47, Julien Rouhaud wrote:
> >
> > First, probably nitpicking, the HEADER MATCH is allowed for COPY TO, is that
> > expected?  The documentation isn't really explicit about it, but there's
> > nothing to match when exporting data it's a bit surprising.  I'm not opposed to
> > have HEADER MATCH means HEADER ON for COPY TO, as as-is one can easily reuse
> > the commands history, but maybe it should be clearly documented?
> 
> 
> I think it makes more sense to have a sanity check to prevent HEADER
> MATCH with COPY TO.

I'm fine with it.  I added such a check and mentioned it in the documentation.

> > Then, apparently HEADER MATCH doesn't let you do sanity checks against a custom
> > column list.  This one looks like a clear oversight, as something like that
> > should be entirely valid IMHO:
> >
> > CREATE TABLE tbl(col1 int, col2 int);
> > COPY tbl (col2, col1) TO '/path/to/file' WITH (HEADER MATCH);
> > COPY tbl (col2, col1) FROM '/path/to/file' WITH (HEADER MATCH);
> >
> > but right now it errors out with:
> >
> > ERROR:  column name mismatch in header line field 1: got "col1", expected "col2"
> >
> > Note that the error message is bogus if you specify attributes in a
> > different order from the relation, as the code is mixing access to the tuple
> > desc and access to the raw fields with the same offset.
> > [...]
> I think it should, but a temporary alternative would be to forbid HEADER
> MATCH with explicit column lists until we can make it work right.

I think it would still be problematic if the target table has dropped columns.
Fortunately, as I initially thought the problem is only due to a thinko in the
original commit which used a wrong variable for the raw_fields offset.  Once
fixed (attached v1) I didn't see any other problem in the rest of the logic and
all the added regression tests work as expected.


view thread (46+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Add header support to text format and matching feature
  In-Reply-To: <20220613023213.bj7qjnplvgfmx522@jrouhaud>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox