On Thu, Jul 18, 2024 at 09:37:06AM +0200, Daniel Gustafsson wrote:
> On 18 Jul 2024, at 09:29, Michael Paquier wrote:
>> How about using a new error code in class 58, say a
>> ERRCODE_FILE_NAME_TOO_LONG like in the attached?
>> ERRCODE_DUPLICATE_FILE is like that; it exists just for the mapping
>>
On Thu, Jul 18, 2024 at 09:37:06AM +0200, Daniel Gustafsson wrote:
> On 18 Jul 2024, at 09:29, Michael Paquier wrote:
>> How about using a new error code in class 58, say a
>> ERRCODE_FILE_NAME_TOO_LONG like in the attached?
>> ERRCODE_DUPLICATE_FILE is like that; it exists just for the mapping
>>
> On 18 Jul 2024, at 09:29, Michael Paquier wrote:
> How about using a new error code in class 58, say a
> ERRCODE_FILE_NAME_TOO_LONG like in the attached?
> ERRCODE_DUPLICATE_FILE is like that; it exists just for the mapping
> with EEXIST.
Agreed, that's probably a better option.
--
Daniel Gus
On Fri, Jul 12, 2024 at 10:41:14PM +0200, Daniel Gustafsson wrote:
> Mapping this case to ERRCODE_NAME_TOO_LONG seems like a legit improvement,
> even
> though the error is likely to be quite rare in production.
Hmm. This is interesting, still it could be confusing as
ERRCODE_NAME_TOO_LONG is us
On Sun, Jul 14, 2024 at 07:00:00PM +0300, Alexander Lakhin wrote:
> I've filed a bug report about the "WITH RECURSIVE" anomaly: [1], but what
> I wanted to understand when presenting different error kinds is what
> definition XX000 errors could have in principle?
Cool, thanks! I can see that Tom
Hello Daniel and Michael,
12.07.2024 23:41, Daniel Gustafsson wrote:
On 10 Jul 2024, at 06:42, Michael Paquier wrote:
The rest mentioned upthread seems either not worth the effort or are likely to
be bugs warranting proper investigation.
I've filed a bug report about the "WITH RECURSIVE" an
> On 10 Jul 2024, at 06:42, Michael Paquier wrote:
>> SELECT format('BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>> SET TRANSACTION SNAPSHOT ''%s''', repeat('-', 1000))
>> \gexec
>> ERROR: XX000: could not open file "pg_snapshots/-...---" for reading:
>> File name too long
>> LOCATION:
On Mon, Jul 08, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
> Let me show you other error types for discussion/classification:
> SELECT pg_describe_object(1::regclass, 0, 0);
>
> ERROR: XX000: unsupported object class: 1
> LOCATION: getObjectDescription, objectaddress.c:4016
> or
> SELECT
Hello Michael,
05.07.2024 03:57, Michael Paquier wrote:
On Thu, Jul 04, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote:
Could you please share your thoughts regarding other error cases, which is
not triggered by existing tests, but still can be easily reached by users?
For example:
SELECT sa
On Thu, Jul 04, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote:
> Could you please share your thoughts regarding other error cases, which is
> not triggered by existing tests, but still can be easily reached by users?
>
> For example:
> SELECT satisfies_hash_partition(1, 1, 0, 0);
>
> ERROR: X
Hello Michael,
04.07.2024 03:51, Michael Paquier wrote:
On Sat, May 18, 2024 at 10:56:43AM +0900, Michael Paquier wrote:
Thanks. I'll look again at that once v18 opens up for business.
Looked at that again, and one in tablecmds.c is not needed anymore,
and there was a conflict in be-secure-op
On Sat, May 18, 2024 at 10:56:43AM +0900, Michael Paquier wrote:
> Thanks. I'll look again at that once v18 opens up for business.
Looked at that again, and one in tablecmds.c is not needed anymore,
and there was a conflict in be-secure-openssl.c. Removed the first
one, fixed the second one, the
On Fri, May 17, 2024 at 01:41:29PM -0400, Robert Haas wrote:
> On Tue, Apr 23, 2024 at 12:55 AM Michael Paquier wrote:
>> Thoughts?
>
> The patch as proposed seems fine. Marking RfC.
Thanks. I'll look again at that once v18 opens up for business.
--
Michael
signature.asc
Description: PGP sign
On Tue, Apr 23, 2024 at 12:55 AM Michael Paquier wrote:
> Thoughts?
The patch as proposed seems fine. Marking RfC.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Apr 29, 2024 at 08:02:45AM -0500, Justin Pryzby wrote:
> I sent a list of user-facing elogs here, a few times.
> ZDclRM/jate66...@telsasoft.com
>
> And if someone had expressed an interest, I might have sent a longer
> list.
Thanks. I'll take a look at what you have there. Nothing would
I sent a list of user-facing elogs here, a few times.
ZDclRM/jate66...@telsasoft.com
And if someone had expressed an interest, I might have sent a longer
list.
Hi all,
While analyzing the use of internal error codes in the code base, I've
some problems, and that's a mixed bag of:
- Incorrect uses, for errors that can be triggered by users with
vallid cases.
- Expected error cases, wanted by the tests like corruption cases or
just to keep some code simp
17 matches
Mail list logo
