On Tue, Apr 02, 2024 at 09:53:57AM +0900, Masahiko Sawada wrote:
> Pushed.
Thanks for following up with this thread.
--
Michael
signature.asc
Description: PGP signature
On Mon, Apr 1, 2024 at 10:03 AM Masahiko Sawada wrote:
>
> On Sat, Mar 30, 2024 at 11:05 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Mar 28, 2024 at 6:31 PM Masahiko Sawada
> > wrote:
> > >
> > > That is,
> > > since the LOG_VERBOSITY option is an enum parameter, it might make
> > > more
On Sat, Mar 30, 2024 at 11:05 PM Bharath Rupireddy
wrote:
>
> On Thu, Mar 28, 2024 at 6:31 PM Masahiko Sawada wrote:
> >
> > That is,
> > since the LOG_VERBOSITY option is an enum parameter, it might make
> > more sense to require the value, instead of making the value optional.
> > For example,
On Thu, Mar 28, 2024 at 6:31 PM Masahiko Sawada wrote:
>
> That is,
> since the LOG_VERBOSITY option is an enum parameter, it might make
> more sense to require the value, instead of making the value optional.
> For example, the following command could not be obvious for users:
>
> COPY test FROM
On 2024-03-28 21:36, torikoshia wrote:
On 2024-03-28 17:27, Bharath Rupireddy wrote:
On Thu, Mar 28, 2024 at 1:43 PM torikoshia
wrote:
Attached patch fixes the doc,
May I know which patch you are referring to? And, what do you mean by
"fixes the doc"?
Ugh, I replied to the wrong thread.
On Thu, Mar 28, 2024 at 5:28 PM Bharath Rupireddy
wrote:
>
> On Thu, Mar 28, 2024 at 1:43 PM torikoshia wrote:
> >
> > Attached patch fixes the doc,
>
> May I know which patch you are referring to? And, what do you mean by
> "fixes the doc"?
>
> > but I'm wondering perhaps it might be
> > better
On 2024-03-28 17:27, Bharath Rupireddy wrote:
On Thu, Mar 28, 2024 at 1:43 PM torikoshia
wrote:
Attached patch fixes the doc,
May I know which patch you are referring to? And, what do you mean by
"fixes the doc"?
Ugh, I replied to the wrong thread.
Sorry for making you confused and please
On Thu, Mar 28, 2024 at 1:43 PM torikoshia wrote:
>
> Attached patch fixes the doc,
May I know which patch you are referring to? And, what do you mean by
"fixes the doc"?
> but I'm wondering perhaps it might be
> better to modify the codes to prohibit abbreviation of the value.
Please help me
On 2024-03-26 17:16, Masahiko Sawada wrote:
On Tue, Mar 26, 2024 at 3:04 PM Bharath Rupireddy
wrote:
On Tue, Mar 26, 2024 at 9:56 AM Masahiko Sawada
wrote:
>
> > > errmsg("data type incompatibility at line %llu for column %s: \"%s\"",
>
> > > I guess it would be better to make the log
On Thu, Mar 28, 2024 at 2:49 AM Bharath Rupireddy
wrote:
>
> On Wed, Mar 27, 2024 at 7:42 AM Masahiko Sawada wrote:
> >
> > I think that there are two options to handle it:
> >
> > 1. change COPY grammar to accept DEFAULT as an option value.
> > 2. change tab-completion to complement 'DEFAULT'
On Wed, Mar 27, 2024 at 7:42 AM Masahiko Sawada wrote:
>
> I think that there are two options to handle it:
>
> 1. change COPY grammar to accept DEFAULT as an option value.
> 2. change tab-completion to complement 'DEFAULT' instead of DEFAULT,
> and update the doc too.
>
> As for the
On Tue, Mar 26, 2024 at 6:36 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 26, 2024 at 1:46 PM Masahiko Sawada wrote:
> >
> > Thank you for updating the patch! Looks good to me.
> >
> > Please find the attached patch. I've made some changes for the
> > documentation and the commit message. I'll
On Tue, Mar 26, 2024 at 1:46 PM Masahiko Sawada wrote:
>
> Thank you for updating the patch! Looks good to me.
>
> Please find the attached patch. I've made some changes for the
> documentation and the commit message. I'll push it, barring any
> objections.
Thanks. v12 patch LGTM.
--
Bharath
On Tue, Mar 26, 2024 at 3:04 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 26, 2024 at 9:56 AM Masahiko Sawada wrote:
> >
> > > > errmsg("data type incompatibility at line %llu for column %s: \"%s\"",
> >
> > > > I guess it would be better to make the log message clearer to convey
> > > > what we
On Tue, Mar 26, 2024 at 9:56 AM Masahiko Sawada wrote:
>
> > > errmsg("data type incompatibility at line %llu for column %s: \"%s\"",
>
> > > I guess it would be better to make the log message clearer to convey
> > > what we did for the malformed row. For example, how about something
> > > like
On Tue, Mar 26, 2024 at 12:23 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 26, 2024 at 7:16 AM Masahiko Sawada wrote:
> >
> > > Please see the attached v9 patch set.
> >
> > Thank you for updating the patch! The patch mostly looks good to me.
> > Here are some minor comments:
>
> Thanks for
On Tue, Mar 26, 2024 at 7:16 AM Masahiko Sawada wrote:
>
> > Please see the attached v9 patch set.
>
> Thank you for updating the patch! The patch mostly looks good to me.
> Here are some minor comments:
Thanks for looking into this.
> ---
> /* non-export function prototypes */
> -static char
On Mon, Mar 25, 2024 at 8:21 PM Bharath Rupireddy
wrote:
>
> On Mon, Mar 25, 2024 at 10:42 AM Masahiko Sawada
> wrote:
> >
> > The current approach, eliminating the duplicated information in
> > CONTEXT, seems good to me.
>
> Thanks for looking into it.
>
> > One question about the latest (v8)
On Mon, Mar 25, 2024 at 10:42 AM Masahiko Sawada wrote:
>
> The current approach, eliminating the duplicated information in
> CONTEXT, seems good to me.
Thanks for looking into it.
> One question about the latest (v8) patch:
>
> + else
> + ereport(NOTICE,
On Wed, Mar 13, 2024 at 11:02 PM Bharath Rupireddy
wrote:
>
> On Wed, Mar 13, 2024 at 11:09 AM Michael Paquier wrote:
> >
> > Hmm. This NOTICE is really bugging me. It is true that the clients
> > would get more information, but the information is duplicated on the
> > server side because the
On Mon, Mar 18, 2024 at 12:05:17PM +0900, Kyotaro Horiguchi wrote:
> And I believe that CONTEXT, if it exists, is augmentation information
> to the primary messages. The objective of the precedent for the use of
> relname_only was somewhat different, but this use also seems legit.
>
> In short, I
At Fri, 15 Mar 2024 16:57:25 +0900, Michael Paquier wrote
in
> On Wed, Mar 13, 2024 at 07:32:37PM +0530, Bharath Rupireddy wrote:
> > I'm attaching the v8 patch set implementing the above idea. With this,
> > [1] is sent to the client, [2] is sent to the server log. This
> > approach not only
On Wed, Mar 13, 2024 at 07:32:37PM +0530, Bharath Rupireddy wrote:
> I'm attaching the v8 patch set implementing the above idea. With this,
> [1] is sent to the client, [2] is sent to the server log. This
> approach not only reduces the duplicate info in the NOTICE and CONTEXT
> messages, but also
On Wed, Mar 13, 2024 at 11:09 AM Michael Paquier wrote:
>
> Hmm. This NOTICE is really bugging me. It is true that the clients
> would get more information, but the information is duplicated on the
> server side because the error context provides the same information as
> the NOTICE itself:
>
On Wed, Mar 13, 2024 at 08:08:42AM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 13, 2024 at 5:16 AM Michael Paquier wrote:
>> The attached 0003 is what I had in mind:
>> - Simplification of the LOG generated with quotes applied around the
>> column name, don't see much need to add the relation
On Wed, Mar 13, 2024 at 5:16 AM Michael Paquier wrote:
>
> On Tue, Mar 12, 2024 at 12:54:29PM +0530, Bharath Rupireddy wrote:
> > +1. But, do you want to add them now or later as a separate
> > patch/discussion altogether?
>
> The attached 0003 is what I had in mind:
> - Simplification of the LOG
On Tue, Mar 12, 2024 at 12:54:29PM +0530, Bharath Rupireddy wrote:
> +1. But, do you want to add them now or later as a separate
> patch/discussion altogether?
The attached 0003 is what I had in mind:
- Simplification of the LOG generated with quotes applied around the
column name, don't see much
On Tue, Mar 12, 2024 at 12:22 PM Michael Paquier wrote:
>
> On Mon, Mar 11, 2024 at 06:00:00PM +0530, Bharath Rupireddy wrote:
> > Please see the attached v6 patch set.
>
> I am tempted to tweak a few things in the docs, the comments and the
> tests (particularly adding more patterns for tuples
On Mon, Mar 11, 2024 at 06:00:00PM +0530, Bharath Rupireddy wrote:
> Please see the attached v6 patch set.
I am tempted to tweak a few things in the docs, the comments and the
tests (particularly adding more patterns for tuples that fail on
conversion while it's clear that there are not enough
On Mon, Mar 11, 2024 at 11:16 AM Michael Paquier wrote:
>
> At the end of the day, this comes down to what is more helpful to the
> user. And I'd agree on the side what ON_ERROR does currently, which
> is what your patch relies on: on the first conversion failure, give up
> and skip the rest of
On Sat, Mar 09, 2024 at 12:01:49AM +0530, Bharath Rupireddy wrote:
> If NOTICE per attribute and incrementing num_errors per row is
> implemented, it ends up erroring out with ERROR: missing data for
> column "m" for all-column-empty-row. Shall we treat this ERROR softly
> too if on_error ignore
On Fri, Mar 8, 2024 at 4:42 PM Michael Paquier wrote:
>
> On Fri, Mar 08, 2024 at 03:36:30PM +0530, Bharath Rupireddy wrote:
> > Please see the attached v5-0001 patch implementing LOG_VERBOSITY with
> > options 'default' and 'verbose'. v5-0002 adds the detailed info to
> > ON_ERROR 'ignore'
On Fri, Mar 08, 2024 at 03:36:30PM +0530, Bharath Rupireddy wrote:
> Please see the attached v5-0001 patch implementing LOG_VERBOSITY with
> options 'default' and 'verbose'. v5-0002 adds the detailed info to
> ON_ERROR 'ignore' option.
I may be reading this patch set incorrectly, but why doesn't
On Thu, Mar 7, 2024 at 12:54 PM Michael Paquier wrote:
>
> On Thu, Mar 07, 2024 at 12:48:12PM +0530, Bharath Rupireddy wrote:
> > I'm okay with it. But, help me understand it better. We want the
> > 'log_verbosity' clause to have options 'default' and 'verbose', right?
> > And, later it can also
On Thu, Mar 07, 2024 at 12:50:33PM +0530, Bharath Rupireddy wrote:
> Nice catch. So, are you suggesting to log one NOTICE message per row
> even if multiple columns in the single row fail to parse or are
> malformed?
One NOTICE per malformed value, I guess, which would be easier to
parse
On Thu, Mar 07, 2024 at 12:48:12PM +0530, Bharath Rupireddy wrote:
> I'm okay with it. But, help me understand it better. We want the
> 'log_verbosity' clause to have options 'default' and 'verbose', right?
> And, later it can also be extended to contain all the LOG levels like
> 'notice',
On Thu, Mar 7, 2024 at 12:37 PM Michael Paquier wrote:
>
> On Thu, Mar 07, 2024 at 03:52:41PM +0900, Masahiko Sawada wrote:
> > One question I have is; do we want to write multiple NOTICE messages
> > for one row if the row has malformed data on some columns?
>
> Good idea. We can do that as the
On Thu, Mar 7, 2024 at 9:30 AM Michael Paquier wrote:
>
> Is a boolean the best interface for the end-user, though? Maybe
> something like a "mode" value would speak more than a yes/no from the
> start, say a "default" mode to emit only the last LOG and a "verbose"
> for the whole set in the
On Thu, Mar 07, 2024 at 03:52:41PM +0900, Masahiko Sawada wrote:
> One question I have is; do we want to write multiple NOTICE messages
> for one row if the row has malformed data on some columns?
Good idea. We can do that as the field strings are already parsed.
--
Michael
signature.asc
On Thu, Mar 7, 2024 at 1:00 PM Michael Paquier wrote:
>
> On Wed, Mar 06, 2024 at 07:32:28PM +0530, Bharath Rupireddy wrote:
> > Please see the attached v4 patch. If it looks good, I can pull
> > LOG_VERBOSITY changes out into 0001 and with 0002 containing the
> > detailed messages for discarded
On 2024-03-07 13:00, Michael Paquier wrote:
On Wed, Mar 06, 2024 at 07:32:28PM +0530, Bharath Rupireddy wrote:
Please see the attached v4 patch. If it looks good, I can pull
LOG_VERBOSITY changes out into 0001 and with 0002 containing the
detailed messages for discarded rows.
The approach
On Wed, Mar 06, 2024 at 07:32:28PM +0530, Bharath Rupireddy wrote:
> Please see the attached v4 patch. If it looks good, I can pull
> LOG_VERBOSITY changes out into 0001 and with 0002 containing the
> detailed messages for discarded rows.
The approach looks sensible seen from here.
+
On Tue, Mar 5, 2024 at 4:48 AM Michael Paquier wrote:
>
> On Mon, Mar 04, 2024 at 05:00:00AM +0530, Bharath Rupireddy wrote:
> > How about an extra option to error_action ignore-with-verbose which is
> > similar to ignore but when specified emits one NOTICE per malformed
> > row? With this, one
On Mon, Mar 04, 2024 at 05:00:00AM +0530, Bharath Rupireddy wrote:
> How about an extra option to error_action ignore-with-verbose which is
> similar to ignore but when specified emits one NOTICE per malformed
> row? With this, one can say COPY x FROM stdin (ON_ERROR
> ignore-with-verbose);.
>
>
On Fri, Mar 1, 2024 at 10:22 AM Michael Paquier wrote:
>
> > Nice catch. When COPY_ON_ERROR_STOP is specified, we use ereport's
> > soft error mechanism. An assertion seems a good choice to validate the
> > state is what we expect. Done that way.
>
> Hmm. I am not really on board with this
On Wed, Feb 28, 2024 at 12:10:00PM +0530, Bharath Rupireddy wrote:
> On Mon, Feb 26, 2024 at 5:47 PM torikoshia wrote:
>> + if (cstate->opts.on_error != COPY_ON_ERROR_STOP)
>> + {
>> + ereport(NOTICE,
>>
>> I think cstate->opts.on_error is not
On Mon, Feb 26, 2024 at 5:47 PM torikoshia wrote:
>
> >
> > It looks good to me.
>
> Here are comments on the v2 patch.
Thanks for looking at it.
> + if (cstate->opts.on_error != COPY_ON_ERROR_STOP)
> + {
> + ereport(NOTICE,
>
> I think
On 2024-02-20 17:22, torikoshia wrote:
On 2024-02-17 15:00, Bharath Rupireddy wrote:
On Fri, Feb 16, 2024 at 8:17 PM torikoshia
wrote:
I may be wrong since I seldom do data loading tasks, but I greed with
you.
I also a little concerned about the case where there are many
malformed
data
On 2024-02-17 15:00, Bharath Rupireddy wrote:
On Fri, Feb 16, 2024 at 8:17 PM torikoshia
wrote:
I may be wrong since I seldom do data loading tasks, but I greed with
you.
I also a little concerned about the case where there are many
malformed
data and it causes lots of messages, but the
On Fri, Feb 16, 2024 at 8:17 PM torikoshia wrote:
>
> I may be wrong since I seldom do data loading tasks, but I greed with
> you.
>
> I also a little concerned about the case where there are many malformed
> data and it causes lots of messages, but the information is usually
> valuable and if
On 2024-02-16 17:15, Bharath Rupireddy wrote:
On Wed, Feb 14, 2024 at 5:04 PM torikoshia
wrote:
[] let the users know what line numbers are
> containing the errors that COPY ignored something like [1] with a
> simple change like [2].
Agreed.
Unlike my patch, it hides the error
On Wed, Feb 14, 2024 at 5:04 PM torikoshia wrote:
>
> [] let the users know what line numbers are
> > containing the errors that COPY ignored something like [1] with a
> > simple change like [2].
>
> Agreed.
> Unlike my patch, it hides the error information(i.e. 22P02: invalid
> input syntax
On 2024-02-12 15:46, Bharath Rupireddy wrote:
Thanks for your comments.
On Mon, Jan 29, 2024 at 8:41 AM torikoshia
wrote:
On 2024-01-27 00:43, David G. Johnston wrote:
>> I'd like to have a new option "log", which skips soft errors and
>> logs
>> information that should have resulted in
On Mon, Jan 29, 2024 at 8:41 AM torikoshia wrote:
>
> On 2024-01-27 00:43, David G. Johnston wrote:
>
> >> I'd like to have a new option "log", which skips soft errors and
> >> logs
> >> information that should have resulted in errors to PostgreSQL log.
> >
> > user-specified tables in the same
On Fri, Jan 26, 2024 at 10:44 PM jian he
wrote:
I doubt the following part:
If the log value is specified,
COPY behaves the same as
ignore, exept that
it logs information that should have resulted in errors to
PostgreSQL log at
INFO level.
I think it does something
On Thu, Jan 25, 2024 at 9:42 AM torikoshia
wrote:
> Hi,
>
> As described in 9e2d870119, COPY ON_EEOR is expected to have more
> "error_action".
> (Note that option name was changed by b725b7eec)
>
> I'd like to have a new option "log", which skips soft errors and logs
> information that should
On Fri, Jan 26, 2024 at 12:42 AM torikoshia wrote:
>
> Hi,
>
> As described in 9e2d870119, COPY ON_EEOR is expected to have more
> "error_action".
> (Note that option name was changed by b725b7eec)
>
> I'd like to have a new option "log", which skips soft errors and logs
> information that should
Hi,
As described in 9e2d870119, COPY ON_EEOR is expected to have more
"error_action".
(Note that option name was changed by b725b7eec)
I'd like to have a new option "log", which skips soft errors and logs
information that should have resulted in errors to PostgreSQL log.
I think this
58 matches
Mail list logo
