Missing File weather.txt

On 28 Jan 2020, at 03:22, PG Doc comments form <noreply@postgresql.org> wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/12/tutorial-populate.html
Description:

On this page https://www.postgresql.org/docs/12/tutorial-populate.html you
have this command:

COPY weather FROM '/home/user/weather.txt';

I've searched all over for weather.txt and can't find it. Please could you
make this and any other files required for the tutorial available and
provide clear instructions for accessing them at the beginning of the
tutorial.

This is only mentioned as an example of another input method, with a link to
the COPY page for more information. That being said, it's a good thing for a
tutorial to be self-contained, and going from a basic tutorial to the COPY
reference page is a fairly large step. I propose that we add a small example
on what weather.txt could look like as per the attached diff.

cheers ./daniel

On 2020/01/28 19:18, Daniel Gustafsson wrote:

On 28 Jan 2020, at 03:22, PG Doc comments form <noreply@postgresql.org> wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/12/tutorial-populate.html
Description:

On this page https://www.postgresql.org/docs/12/tutorial-populate.html you
have this command:

COPY weather FROM '/home/user/weather.txt';

I've searched all over for weather.txt and can't find it. Please could you
make this and any other files required for the tutorial available and
provide clear instructions for accessing them at the beginning of the
tutorial.

This is only mentioned as an example of another input method, with a link to
the COPY page for more information. That being said, it's a good thing for a
tutorial to be self-contained, and going from a basic tutorial to the COPY
reference page is a fairly large step. I propose that we add a small example
on what weather.txt could look like as per the attached diff.

Sorry for reviving this old thread, but I wanted to follow up since
the same issue was reported again in [1]/messages/by-id/175166227769.3157504.1136715805440673517@wrigleys.postgresql.org, and the proposed patch
basically looks good to me.

Regarding the patch:

+<programlisting>
+San Francisco    46    50    0.25    1994-11-27
+Hayward    37    54    0.0    1994-11-29
+</programlisting>

In the tutorial, three rows are inserted using INSERT, so shouldn't
the sample input for COPY include all three, like this?

San Francisco 46 50 0.25 1994-11-27
San Francisco 43 57 0 1994-11-29
Hayward 37 54 \N 1994-11-29

Regards,

[1]: /messages/by-id/175166227769.3157504.1136715805440673517@wrigleys.postgresql.org

--
Fujii Masao
NTT DATA Japan Corporation

Fujii Masao <masao.fujii@oss.nttdata.com> writes:

On 2020/01/28 19:18, Daniel Gustafsson wrote:

This is only mentioned as an example of another input method, with a link to
the COPY page for more information. That being said, it's a good thing for a
tutorial to be self-contained, and going from a basic tutorial to the COPY
reference page is a fairly large step. I propose that we add a small example
on what weather.txt could look like as per the attached diff.

Sorry for reviving this old thread, but I wanted to follow up since
the same issue was reported again in [1], and the proposed patch
basically looks good to me.

+1

In the tutorial, three rows are inserted using INSERT, so shouldn't
the sample input for COPY include all three, like this?

Agreed, the example file should match what the tutorial expects to be
in the table. I'd include text along the lines of "The data inserted
above could also be inserted from a file containing:".

regards, tom lane

On 5 Jul 2025, at 19:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Fujii Masao <masao.fujii@oss.nttdata.com> writes:

On 2020/01/28 19:18, Daniel Gustafsson wrote:

This is only mentioned as an example of another input method, with a link to
the COPY page for more information. That being said, it's a good thing for a
tutorial to be self-contained, and going from a basic tutorial to the COPY
reference page is a fairly large step. I propose that we add a small example
on what weather.txt could look like as per the attached diff.

Sorry for reviving this old thread, but I wanted to follow up since
the same issue was reported again in [1], and the proposed patch
basically looks good to me.

+1

In the tutorial, three rows are inserted using INSERT, so shouldn't
the sample input for COPY include all three, like this?

Agreed, the example file should match what the tutorial expects to be
in the table. I'd include text along the lines of "The data inserted
above could also be inserted from a file containing:".

The attached v2 adds the missing line, and tweaks the text added to document
the file. Since there have been reports I propose backpatching this all the
way down to 13 while at it.

--
Daniel Gustafsson

On 2025/07/11 7:22, Daniel Gustafsson wrote:

On 5 Jul 2025, at 19:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Fujii Masao <masao.fujii@oss.nttdata.com> writes:

On 2020/01/28 19:18, Daniel Gustafsson wrote:

This is only mentioned as an example of another input method, with a link to
the COPY page for more information. That being said, it's a good thing for a
tutorial to be self-contained, and going from a basic tutorial to the COPY
reference page is a fairly large step. I propose that we add a small example
on what weather.txt could look like as per the attached diff.

Sorry for reviving this old thread, but I wanted to follow up since
the same issue was reported again in [1], and the proposed patch
basically looks good to me.

+1

In the tutorial, three rows are inserted using INSERT, so shouldn't
the sample input for COPY include all three, like this?

Agreed, the example file should match what the tutorial expects to be
in the table. I'd include text along the lines of "The data inserted
above could also be inserted from a file containing:".

The attached v2 adds the missing line, and tweaks the text added to document
the file.

Thanks for updating the patch! LGTM.

Just one small comment:

+Hayward 37 54 0.0 1994-11-29

This row is inserted using the following INSERT statement:

INSERT INTO weather (date, city, temp_hi, temp_lo)
VALUES ('1994-11-29', 'Hayward', 54, 37);

Since the prcp column isn't specified, its value is NULL. So shouldn't
the fourth field in the data line above be \N instead of 0.0?

Since there have been reports I propose backpatching this all the
way down to 13 while at it.

+1

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

On 11 Jul 2025, at 01:36, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:

Since the prcp column isn't specified, its value is NULL. So shouldn't
the fourth field in the data line above be \N instead of 0.0?

It should, fixed in v3.

--
Daniel Gustafsson

On 2025/07/12 7:18, Daniel Gustafsson wrote:

On 11 Jul 2025, at 01:36, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:

Since the prcp column isn't specified, its value is NULL. So shouldn't
the fourth field in the data line above be \N instead of 0.0?

It should, fixed in v3.

LGTM. Thanks!

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

Fujii Masao <masao.fujii@oss.nttdata.com> writes:

On 2025/07/12 7:18, Daniel Gustafsson wrote:

It should, fixed in v3.

LGTM. Thanks!

I'm okay with this too. I find myself niggling a bit at the
parenthetical remark "the white space on each line is actually a tab
character". There's several tabs on each line, so use of the singular
isn't quite right. However, the best alternative phrasing I could
come up with is "each instance of white space is actually a single tab
character", and that doesn't seem any more understandable. So maybe
it's best left as you have it.

regards, tom lane

On 12 Jul 2025, at 18:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Fujii Masao <masao.fujii@oss.nttdata.com> writes:

On 2025/07/12 7:18, Daniel Gustafsson wrote:
It should, fixed in v3.

LGTM. Thanks!

I'm okay with this too. I find myself niggling a bit at the
parenthetical remark "the white space on each line is actually a tab
character". There's several tabs on each line, so use of the singular
isn't quite right. However, the best alternative phrasing I could
come up with is "each instance of white space is actually a single tab
character", and that doesn't seem any more understandable. So maybe
it's best left as you have it.

Or perhaps ”values are separated by a tab character”?

./daniel

Daniel Gustafsson <daniel@yesql.se> writes:

Or perhaps ”values are separated by a tab character”?

WFM

regards, tom lane

On 12 Jul 2025, at 18:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Daniel Gustafsson <daniel@yesql.se> writes:

Or perhaps ”values are separated by a tab character”?

WFM

Thanks, I'll get this pushed once the freeze is over on REL_18_STABLE.

--
Daniel Gustafsson