Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Sergei Katkovsky]

On Thu, Oct 16, 2025 at 10:11 PM David G. Johnston
 wrote:

> The spaces added to the end of a bpchar manually can and are considered 
> “padding” - or “present but lack semantic/value significance”. The reason 
> they are not padding for varchar is that such spaces are considered part of 
> the stored value from a semantic perspective.
>
> Think of padding as a noun, not a verb.  “The value contains padding”.  Not, 
> “ I am padding the value”.

The value may sometimes contain padding. And sometimes not. But we are
talking about the type, not value. The value 'abc'::bpchar does not
contain any blanks. But it's still a BPCHAR value.  And it is not
padded, despite that its type is BPCHAR.

> And yes, this is intended as a way to make the name of the type and its 
> behavior consistent.

The behavior of 'abc'::BPCHAR is, for example, the following:
length('abc'::BPCHAR) = 3
CONCAT('abc::BPCHAR, 'def') = 'abcdef'.
What of the above is consistent with the notion of being 'blank-padded'?

And, the proposal is not to change the name of the type. The proposal
is to change the wording 'blank-trimming' to something more
appropriate.

> You sorta have to want it to work/make sense; not fight it on minor nuance.

The sole reason that I am here is that recently I came across a
(year-old) question on stackoverflow where some person was curious why
the actual behavior of BPCHAR was inconsistent with the documentation.
What is worse is that the question was answered, but answered
incorrectly. So, I doubt that it is just a minor nuance. Probably, not
just one person tried to use BPCHAR as a 'blank-trimming' type.

With best regards,
Sergei Katkovskii

Can not close psql

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/18/app-psql.html
Description:

Hello.
I was connected to database via `psql` then I rebooted DB. I was not able to
disconnect from terminal after that. Only whole window close helped.

```
userdb=>
userdb=> \d
FATAL:  terminating connection due to administrator command
SSL connection has been closed unexpectedly
The connection to the server was lost. Attempting reset:
^C^C^C^C


^C^C^C^C^C


^C^C^C^C^C
^X^Z
3
asdf

dfafasf




^C^C^C^C^C^C^C
```

It would be nice if `psql` allows to disconnect from console if a connection
to database was lost.

Re: UNION does not append

[David G. Johnston]

On Tuesday, October 7, 2025, PG Doc comments form 
wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/18/queries-union.html
> Description:
>
> I'm very confused about this statement in the documentation of UNION:
> "UNION
> effectively appends the result of query2 to the result of query1".
> Because, if I append one item to a list, it is still the same list. But in
> the case of UNION, it's ""copied"" into a new anonymous derived-table.
> Alias
> don't work anymore, which I would expect if I just append some rows. Or is
> it like "effectively" means that this statement is not to be taken
> literally? In that case I would really appreciate a more detailed
> description, that after the UNION with tables a new anonymous derived-table
> is returned and the original first table can't be accessed anymore. Thank
> you for taking your time to read this even if you disagree.
>

Yes, if you place a set-operation using query into a subquery context the
subquery has to be given its own name: and the individual from clause
relations of the contained query are not exposed.  This is just how
subqueries work.

If you don’t place it in a subquery the rows are just sent to the client.

In both cases the word append simply means “using the column structure of
the first component query”.  Though Imsuppose that is strictly “column
names” since types can be changed to a more encompassing one if needed.

David J.

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Sergei Katkovsky]

On Fri, Oct 17, 2025 at 1:08 AM David G. Johnston
 wrote:
>
>
> I’m just trying to phrase the documentation for bpchar so that the “bp”, 
> which stands for “blank-padded”, is justified.

That's what I thought. Yes, unfortunately, bp stands for
“blank-padded”, but this name is wrong and misleading. I don't know
why it was chosen, maybe it was actually considered as blank-padded at
that time, maybe it was an attempt to avoid introducing a new keyword
(an ancient curse that has ruined a lot of good ideas already). It
doesn't matter, though. That was a mistake in my opinion, but we don't
have to repeat it. There is no need to justify wrongs. An honest
remark (footnote, tip, whatever) in documentation "Although BP in
BPCHAR stands for 'blank-padded', no padding is actually performed for
this type" would be far better.

>
> I do understand the terminology confusion with the verb padding.  And see why 
> “trimmed” is actively confusing.  The prose probably needs to resolve this - 
> and technically does from what I’m reading.
>
> You may wish to move on from critiquing my suggested changes and instead 
> propose something concrete of your own.  Provide a third choice besides 
> status-quo and my option.

I already did this. It was my original request that started this
discussion, and I suggested there, although more as a guide,
"as-if-blank-trimmed" and "blank-ignoring". But then Jeff Davis
prepared a patch and proposed "blank-insignificant" instead, which I
support now (after that, I also suggested "blank-agnostic", but that
was more of a joke). So, the third choice already exists, and there is
even a patch implementing it.

Of course, "blank-insignificant" is not perfect either, specifically,
it's not immediately obvious that only trailing blanks are
insignificant here. Perhaps a better term would be
"trailing-blanks-insignificant", with or without hyphens. But in my
opinion. both are much more appropriate and less misleading than
either "blank-padded" or "blank-trimmed".

>
> Though I’m doubtful there is a nice precise hyphenated word to be found here 
> for “treats any trailing spaces as being semantically insignificant”.

Yes, but nobody requires us to use such a word here. We can use a few
more words if needed.


With best regards,
Sergei Katkovskii

Re: DDL Partitionion Inheritance -- improved trigger function

[David Rowley]

On Wed, 24 Sept 2025 at 04:25, Kirk Parker  wrote:
> I'm a big fan of maintenance-free functions.  What would you think about 
> adding the following as an alternative trigger function, or as a replacement 
> for the current function, to
> https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-INHERITANCE-EXAMPLE
>  , item #5?
>
> CREATE OR REPLACE FUNCTION measurement_insert_trigger()
> RETURNS TRIGGER AS $$
> BEGIN
> EXECUTE format('INSERT INTO measurement_%s VALUES (NEW.*)', to_char( 
> NEW.logdate, 'MM'));
> RETURN NULL;
> END;
> $$
> LANGUAGE plpgsql;

I've somewhat mixed feelings about that. While I do agree that it
might be a good way to code things to help prevent a DBA from a
midnight callout, I'm just not sure I'm that onboard with adding the
example. About 10 years ago, I'd likely just have agreed, but since
then we've got declarative partitioning and the legitimate use cases
for using inheritance partitioning over the newer method are very
limited. Today when I look at that page in the documents, I wonder how
we could write less about inheritance partitioning or if we could move
the inheritance section out into another page rather than having it
mixed up with the declarative partitioning sections, perhaps headed up
with a note to redirect people to the declarative partitioning
section. I fear adding your proposed example might increase the
chances of someone landing on that section if they're skimming the
page.

Overall, I'm about -0.01 on your idea. I might be in favour of it if
the inheritance section had a dedicated page.

David

Re: Little Typo on Presskit 18

[Daniel Gustafsson]

> On 6 Oct 2025, at 11:05, William Sescu (Suva)  wrote:
> 
> Dear PostgreSQL Docs List
>  I think, I found a little typo in the Presskit 18 docs.
>  https://www.postgresql.org/about/press/presskit18/en/
>  It says:
> PostgreSQL 18 comes with HTML documentation HTML documentation as well as man 
> pages, and you can also browse the documentation online in both HTML and PDF 
> formats.
>  Should be:
>  PostgreSQL 18 comes with HTML documentation as well as man pages, and you 
> can also browse the documentation online in both HTML and PDF 

Thanks for the report, and a very nice catch it is, turns out this duplication
has existed in every presskit since Postgres v11..

I've removed it from the v18 presskit but I opted to leave it in the older kits
as they exist as historic records at this point.

--
Daniel Gustafsson

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Tom Lane]

Jeff Davis  writes:
> Please take a look at the attached patch. If you'd like your name
> included in the commit, please send it as you'd like it to appear.

I don't understand why any of these variants are better than the
original wording "blank-padded".  That has the non-negligible
advantage of corresponding to the type name, and furthermore
appears in many other places in our docs and source code.

There may be some other wording improvements we could make here,
but I think b69db5173 was fundamentally misguided in this respect.

regards, tom lane

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Sergei Katkovsky]

Hello,

>  I think "blank-insignificant" is slightly better than "blank-ignoring".

Yes, I agree. And there is also "blank-agnostic" if you prefer fancy
expressions :)

>  Please take a look at the attached patch. If you'd like your name
>  included in the commit, please send it as you'd like it to appear.

The patch is correct, in my opinion. Although it would be nice to have
additionally a clear explanation in which contexts blanks in BPCHAR are
insignificant (like in comparison) and in which they are still
meaningful (like in concatenation), that issue could be addressed later
separately, and maybe not even in the docs but rather in wiki.

Regarding my name. I'm new to this list, so I didn't quite understand what
you were asking for exactly. If you just need to know the spelling of my
name, it's Sergei Katkoskii.

With best regards,
Sergei Katkovskii

Little Typo on Presskit 18

[William Sescu (Suva)]

Dear PostgreSQL Docs List

I think, I found a little typo in the Presskit 18 docs.

https://www.postgresql.org/about/press/presskit18/en/

It says:
PostgreSQL 18 comes with HTML documentation HTML documentation as well as man 
pages, and you can also browse the documentation online in both 
HTML and 
PDF 
formats.

Should be:

PostgreSQL 18 comes with HTML documentation as well as man pages, and you can 
also browse the documentation online in both 
HTML and 
PDF 
formats.


Cheers
William



Disclaimer:

Diese Nachricht und ihr eventuell angehängte Dateien sind nur für den 
Adressaten bestimmt. Sie kann vertrauliche oder gesetzlich geschützte Daten 
oder Informationen beinhalten. Falls Sie diese Nachricht irrtümlich erreicht 
hat, bitten wir Sie höflich, diese unter Ausschluss jeglicher Reproduktion zu 
löschen und die absendende Person zu benachrichtigen. Danke für Ihre Hilfe.

This message and any attached files are for the sole use of the recipient named 
above. It may contain confidential or legally protected data or information. If 
you have received this message in error, please delete it without making any 
copies whatsoever and notify the sender. Thank you for your assistance.


smime.p7s
Description: S/MIME cryptographic signature

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Sergei Katkovsky]

On Fri, Oct 17, 2025 at 5:46 PM David G. Johnston
 wrote:

> "Insignificant trailing blanks."

OK, looks good to me too.

With best regards,
Sergei Katkovskii

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[David G. Johnston]

On Thursday, October 16, 2025, Jeff Davis  wrote:

> On Thu, 2025-10-16 at 08:36 -0400, David G. Johnston wrote:
> > A given value has a finite length and there is just no restriction on
> > what that length is.  All trailing spaces in the input are considered
> > padding for purposes of comparison i.e., manually padding is added by
> > the user as opposed to the system.
>
> I see -- so it means that the padding came from somewhere else (not the
> type).
>

Yeah, your original conclusion this couldn’t be labeled blank-padded seems
to have drawn this confusion.  If padding is indeed noun-like and not
verb-like then calling it blank-padded works ok.  The clarifying text is
then just fine as-is: the comment about any included spaces are
semantically insignificant ties back to calling those spaces “padding” and
thus the type itself remains “blank-padded” in both the and N and non-N
cases.  There isn’t a way to make “trimmed” a noun here but those spaces
are not actually removed/trimmed away.

In short, I would change trimmed to padded in the table.

I’d also add “padding” here just to actually use the word in its noun form.

…but trailing spaces are [stored as] semantically insignificant [padding].

(I thought also about trying to remove the phrase “semantically
[in]significant” altogether but at the moment would rather not touch the
following paragraph.)

If we really have to drive the point home I'd also add a footnote marker to
“blank-padded” and then say in the footnote text (right below the table):
A blank-padded value contains zero or more trailing spaces which are
ignored for comparison purposes.  These spaces are also called
“semantically insignificant”.

David J.

doc: Fix missing closing parentheses in monitoring.sgml

[Shinya Kato]

Hi,

Attached is a doc-only fix that adds a missing closing parenthesis in
monitoring.sgml (pg_stat_progress_analyze: delay_time).

-- 
Best regards,
Shinya Kato
NTT OSS Center


v1-0001-doc-Fix-missing-closing-parentheses-in-monitoring.patch
Description: Binary data

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Sergei Katkovsky]

On Fri, Oct 17, 2025 at 4:49 PM Laurenz Albe  wrote:

> "bpchar" and "varchar", when used without type modifier, are actually
> identical:
>
> SELECT octet_length(BPCHAR 'x   '),
>octet_length(VARCHAR 'x   '),
>octet_length(TEXT 'x   ');
>
>  octet_length │ octet_length │ octet_length
> ══╪══╪══
> 4 │4 │4
>
> The blank-trimming only occurs when a "bpchar" is converted to "text",
> for example when used with the concatenation operator.

Unfortunately, BPCHAR and VARCHAR are not identical in other contexts.
The situation is not the same as with BCHAR(n), which is just an alias
for CHAR(n).
SELECT BPCHAR 'x' = VARCHAR 'x   ', VARCHAR 'x' = BPCHAR 'x   ',
VARCHAR 'x' = VARCHAR 'x   ';
true true false
For comparison with BPCHAR trailing blanks are insignificant, but when
we have VARCHAR on both sides, they matter.

With best regards,
Sergei Katkovskii

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[David G. Johnston]

On Fri, Oct 17, 2025, 03:38 Sergei Katkovsky  wrote:

> Perhaps a better term would be
> "trailing-blanks-insignificant", with or without hyphens.
>

"Insignificant trailing blanks."

David J.

UNION does not append

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/18/queries-union.html
Description:

I'm very confused about this statement in the documentation of UNION: "UNION
effectively appends the result of query2 to the result of query1".
Because, if I append one item to a list, it is still the same list. But in
the case of UNION, it's ""copied"" into a new anonymous derived-table. Alias
don't work anymore, which I would expect if I just append some rows. Or is
it like "effectively" means that this statement is not to be taken
literally? In that case I would really appreciate a more detailed
description, that after the UNION with tables a new anonymous derived-table
is returned and the original first table can't be accessed anymore. Thank
you for taking your time to read this even if you disagree.

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Jeff Davis]

On Wed, 2025-10-15 at 15:29 -0400, Tom Lane wrote:
> Jeff Davis  writes:
> > Please take a look at the attached patch. If you'd like your name
> > included in the commit, please send it as you'd like it to appear.
> 
> I don't understand why any of these variants are better than the
> original wording "blank-padded".  That has the non-negligible
> advantage of corresponding to the type name, and furthermore
> appears in many other places in our docs and source code.

I don't have a strong opinion on the subject, but I'll explain the
reasoning:

"Padded" is confusing in the sense that it raises the question: "padded
to what length?". Since bpchar doesn't have a specific length
associated with it, then it's just taking the spaces that went into the
type input function, which doesn't sound like "padding" in the same
sense as CHAR(10).

Regards,
Jeff Davis

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[David G. Johnston]

On Thursday, October 16, 2025, Sergei Katkovsky 
wrote:

> On Thu, Oct 16, 2025 at 10:11 PM David G. Johnston
>  wrote:
>
> > The spaces added to the end of a bpchar manually can and are considered
> “padding” - or “present but lack semantic/value significance”. The reason
> they are not padding for varchar is that such spaces are considered part of
> the stored value from a semantic perspective.
> >
> > Think of padding as a noun, not a verb.  “The value contains padding”.
> Not, “ I am padding the value”.
>
> The value may sometimes contain padding. And sometimes not.

But we are
> talking about the type, not value.


We are talking about the properties of values stored within the type and
the behavior during their construction and use.  For bpchar those values
have no length limitation and any trailing spaces present are considered
padding.



> And, the proposal is not to change the name of the type. The proposal
> is to change the wording 'blank-trimming' to something more
> appropriate.


I’m on board with that.  Blank-padded is IMO the best “more appropriate”
choice.

In PostgreSQL the behavior and stored contents/representation of a value
are not influenced by a type modifier.  It is only used during input to
perform some either or both a validation or transformation.  Here, when
present, it performs a padding transform.  But present or absent, trailing
spaces, if any, are considered padding.  The prose for the section talk
about the two key pieces: (n) imposes a length limit while also
transforming an input by adding padding spaces.  The non-n case has
unlimited length and no transformation.  Post-construction, all trailing
spaces are treated as padding.

David J.

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Jeff Davis]

On Thu, 2025-10-16 at 08:36 -0400, David G. Johnston wrote:
> A given value has a finite length and there is just no restriction on
> what that length is.  All trailing spaces in the input are considered
> padding for purposes of comparison i.e., manually padding is added by
> the user as opposed to the system.

I see -- so it means that the padding came from somewhere else (not the
type).

> I would leave the note of blank-padded for both and just point out
> the automatic vs manual distinction.

Yeah, it's a table, so if a user is confused, they can read the text
below it. I'm fine with that.

If you think the text below should be improved, do you have a wording
suggestion?

Regards,
Jeff Davis

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Laurenz Albe]

On Fri, 2025-10-17 at 18:18 +0400, Sergei Katkovsky wrote:
> On Fri, Oct 17, 2025 at 4:49 PM Laurenz Albe  wrote:
> 
> > "bpchar" and "varchar", when used without type modifier, are actually
> > identical:
> > 
> > SELECT octet_length(BPCHAR 'x   '),
> >     octet_length(VARCHAR 'x   '),
> >     octet_length(TEXT 'x   ');
> > 
> >   octet_length │ octet_length │ octet_length
> > ══╪══╪══
> >  4 │    4 │    4
> > 
> > The blank-trimming only occurs when a "bpchar" is converted to "text",
> > for example when used with the concatenation operator.
> 
> Unfortunately, BPCHAR and VARCHAR are not identical in other contexts.
> The situation is not the same as with BCHAR(n), which is just an alias
> for CHAR(n).
> SELECT BPCHAR 'x' = VARCHAR 'x   ', VARCHAR 'x' = BPCHAR 'x   ',
> VARCHAR 'x' = VARCHAR 'x   ';
> true true false
> For comparison with BPCHAR trailing blanks are insignificant, but when
> we have VARCHAR on both sides, they matter.

They are stored identically, but behave differently, so I shouldn't have
said that they *are* identical.

Still, they all are variable-length strings, so we could list them together.

But perhaps it is really better to leave things as they are now, perhaps
replacing "blank-trimming", perhaps as "variable-length string that ignores
training blanks".

Yours,
Laurenz Albe

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Sergei Katkovsky]

> I don't understand why any of these variants are better than the
> original wording "blank-padded".  That has the non-negligible
> advantage of corresponding to the type name, and furthermore
> appears in many other places in our docs and source code.

The wording for BPCHAR (not to be confused with BPCHAR(N) is already
"blank-trimming", not "blank-padded". And "blank-padded" is probably
the least correct wording variant for BPCHAR, because this type has
unlimited length and it's impossible to pad to the infinity.

The following example (slight modification of my original example, I
replaced varchar with bpchar(6)) can perhaps explain the difference.

SELECT  length(bpchar_val) as bplen, concat('[', bpchar_val, ']') as bpbrack
, length(char6_val) as c6len, concat('[', char6_val, ']') as c6brack
FROM (VALUES
('abc   '::bpchar, 'abc   '::bpchar(6)),
('abc   '::bpchar, 'abc'::bpchar(6)),
('abc'::bpchar, 'abc   '::bpchar(6)),
('abc'::bpchar, 'abc'::bpchar(6)))
AS bpchar_test (bpchar_val, char6_val)
WHERE bpchar_val = char6_val;

There results are:
bplen  bpbrack   c6len  c6brack
3  [abc   ]  3  [abc   ]
3  [abc   ]  3  [abc   ]
3  [abc] 3  [abc   ]
3  [abc] 3  [abc   ]

As you can see, there are four rows, so, comparison ignores blanks,
length() also ignores blank, but the results of concatenation show
that while BPCHAR(6) was actually padded to 6 characters ('abc' became
'abc   '), BPCHARwas not. 'abc' remained 'abc'. Therefore, I don't
think it's a good idea to call BPCHAR "blank-padded".

With best regards,
Sergei Katkovskii

Re: Little Typo on Presskit 18

[Álvaro Herrera]

On 2025-Oct-06, Daniel Gustafsson wrote:

> Thanks for the report, and a very nice catch it is, turns out this duplication
> has existed in every presskit since Postgres v11..
> 
> I've removed it from the v18 presskit but I opted to leave it in the older 
> kits
> as they exist as historic records at this point.

I don't understand how this could have happened.  The duplication is not
present in the Markdown files in the press Git repository.  Is this a
problem in the tooling that produces the HTML files from the Markdown
source?  Given that the typo has been produced for several years now,
it's clearly not simple human error, but I suspect a buggy script ...

-- 
Álvaro HerreraBreisgau, Deutschland  —  https://www.EnterpriseDB.com/

Use uppercase keywords in foreign key tutorial

[Erik Wienhold]

While browsing the docs I saw that the foreign key tutorial [1] uses
some lowercase keywords which are inconsistent with the rest of the
docs.  The attached patch fixes that.  Should be pushed to all stable
branches.

[1] https://www.postgresql.org/docs/current/tutorial-fk.html

-- 
Erik Wienhold
>From c4fe1831fedc07ebb123c6cdc79eb97b32a1847c Mon Sep 17 00:00:00 2001
From: Erik Wienhold 
Date: Thu, 16 Oct 2025 10:30:21 +0200
Subject: [PATCH] doc: Use uppercase keywords in foreign key tutorial

Make it consistent with the rest of the docs.
---
 doc/src/sgml/advanced.sgml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index e15a3323dfb..1f37dc73be8 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -101,12 +101,12 @@ SELECT * FROM myview;
 
 
 CREATE TABLE cities (
-name varchar(80) primary key,
+name varchar(80) PRIMARY KEY,
 location point
 );
 
 CREATE TABLE weather (
-city  varchar(80) references cities(name),
+city  varchar(80) REFERENCES cities(name),
 temp_lo   int,
 temp_hi   int,
 prcp  real,
-- 
2.51.0

Re: Documentation improvement patch

[Daniel Gustafsson]

> On 10 Sep 2025, at 09:54, Oleg  wrote:
> 
> Dear all,
> I have prepared a patch containing some minor inconsistencies in the 
> documentation. Please, take a look.
> I will be looking forward to your feedback.

Thanks for the patch, while most of these are obvious improvements I have a few
comments on some:


-   Change the definition of a replication slot.
+   Changes the definition of a replication slot.
Reading this page it seems we are mixing tense in many places, some say "Change
the" and "Read some" and elsewhere we use "Drops the".  Maybe a more holistic
approach would be better for this page to improve consistency?


-   Not enabled by default because it is resource intensive.
+   Not enabled by default because it is resource-intensive.
We use both spellings in multiple places, shouldn't all be changed?


-   COPY and other file-access functions.
+   the COPY command and file-access functions.
...
-   COPY and other file-access functions.
+   the COPY command and file-access functions.
...
-   COPY and other functions which allow executing a
+   the COPY command and functions, which allow 
executing a
I'm not sure about these, I think we use COPY without the the "the COPY
command" decoration in many places so I think it's more consistent like this.


- to call functions defined in the standard internal library, by using an
+ to call functions defined in the standard internal function library by 
using an
  interface similar to their SQL signature.
Isn't it a bit redundant to say "internal function library" when we are already
talking about function definitions?

> The patch shall be applied to the REL_18_STABLE branch.

As you mentioned downthread, this is also for master.  Our workflow is to
always apply to master and backpatch from there.

--
Daniel Gustafsson

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[Laurenz Albe]

On Wed, 2025-10-15 at 15:29 -0400, Tom Lane wrote:
> Jeff Davis  writes:
> > Please take a look at the attached patch. If you'd like your name
> > included in the commit, please send it as you'd like it to appear.
> 
> I don't understand why any of these variants are better than the
> original wording "blank-padded".  That has the non-negligible
> advantage of corresponding to the type name, and furthermore
> appears in many other places in our docs and source code.
> 
> There may be some other wording improvements we could make here,
> but I think b69db5173 was fundamentally misguided in this respect.

My suggestion is to just remove the "blank-trimmed" from the documentation.

"bpchar" and "varchar", when used without type modifier, are actually
identical:

SELECT octet_length(BPCHAR 'x   '),
   octet_length(VARCHAR 'x   '),
   octet_length(TEXT 'x   ');

 octet_length │ octet_length │ octet_length 
══╪══╪══
4 │4 │4

The blank-trimming only occurs when a "bpchar" is converted to "text",
for example when used with the concatenation operator.

I suggest the following simplification:

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index b81d89e2608..05edab3bd33 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1177,11 +1177,7 @@ SELECT '52093.89'::money::numeric::float8;
 fixed-length, blank-padded


-bpchar
-variable unlimited length, blank-trimmed
-   
-   
-text
+text, varchar, 
bpchar
 variable unlimited length

  

Yours,
Laurenz Albe

Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

[David G. Johnston]

On Friday, October 17, 2025, Laurenz Albe  wrote:

>
> I suggest the following simplification:
>
> +text, varchar,
> bpchar
>
>
Calling bpchar an alias of text/varchar does not improve matters.  Sure,
the type itself doesn’t actually care about trailing spaces, but in
practice operations on bpchar values do not behave the same as those on
text values.

select '123  '::bpchar = '123'::bpchar; // true

David J.