Re: Error building for 64-bit Windows (10)

[Michael Paquier]

On Mon, May 17, 2021 at 08:07:02PM +, PG Doc comments form wrote:
> The Solution.pm file has the following lines:
>   if ($self->{options}->{gss})
>   {
>   $proj->AddIncludeDir($self->{options}->{gss} . '\inc\krb5');
>   $proj->AddLibrary($self->{options}->{gss} . 
> '\lib\i386\krb5_32.lib');
>   $proj->AddLibrary($self->{options}->{gss} .
> '\lib\i386\comerr32.lib');
>   $proj->AddLibrary($self->{options}->{gss} .
> '\lib\i386\gssapi32.lib');
>   }
> I had to change them to the following or the compiling failed:
>   if ($self->{options}->{gss})
>   {
>   $proj->AddIncludeDir($self->{options}->{gss} . '\include');
>   $proj->AddIncludeDir($self->{options}->{gss} . '\include\krb5');
>   $proj->AddLibrary($self->{options}->{gss} . 
> '\lib\amd64\krb5_64.lib');
>   $proj->AddLibrary($self->{options}->{gss} . 
> '\lib\amd64\comerr64.lib');
>   $proj->AddLibrary($self->{options}->{gss} . 
> '\lib\amd64\gssapi64.lib');

Yes, you are right.  I have been playing with the deliverables we
recommend in the docs as of [1], and there are a couple of gotchas
here:
- For the 32b and 64b MSI installer, the include path is not "inc",
but "include".  So I could not get the installation on Win32 to work
either on HEAD.
- There is a sub-path called "include/krb5", which is not really
necessary except if we use krb5.h, but we don't.  Upstream code
recommends actually to use krb5/krb5.h, meaning that only "include/"
would be sufficient.  Keeping "include/krb5/" around is not a big deal
either.

This has not been changed in ages, so perhaps few have bothered.
Anyway, the attached patch fixes both the 32b and 64b builds for me.
Another interesting thing is that the installation of krb5 for amd64
and i386 cannot co-exist together, so installing one removes the
second automatically.

[1]: https://web.mit.edu/Kerberos/dist/index.html
--
Michael
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 3c5fe5dddc..05866af925 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -1023,10 +1023,20 @@ sub AddProject
 	}
 	if ($self->{options}->{gss})
 	{
-		$proj->AddIncludeDir($self->{options}->{gss} . '\inc\krb5');
-		$proj->AddLibrary($self->{options}->{gss} . '\lib\i386\krb5_32.lib');
-		$proj->AddLibrary($self->{options}->{gss} . '\lib\i386\comerr32.lib');
-		$proj->AddLibrary($self->{options}->{gss} . '\lib\i386\gssapi32.lib');
+		$proj->AddIncludeDir($self->{options}->{gss} . '\include');
+		$proj->AddIncludeDir($self->{options}->{gss} . '\include\krb5');
+		if ($self->{platform} eq 'Win32')
+		{
+			$proj->AddLibrary($self->{options}->{gss} . '\lib\i386\krb5_32.lib');
+			$proj->AddLibrary($self->{options}->{gss} . '\lib\i386\comerr32.lib');
+			$proj->AddLibrary($self->{options}->{gss} . '\lib\i386\gssapi32.lib');
+		}
+		else
+		{
+			$proj->AddLibrary($self->{options}->{gss} . '\lib\amd64\krb5_64.lib');
+			$proj->AddLibrary($self->{options}->{gss} . '\lib\amd64\comerr64.lib');
+			$proj->AddLibrary($self->{options}->{gss} . '\lib\amd64\gssapi64.lib');
+		}
 	}
 	if ($self->{options}->{iconv})
 	{


signature.asc
Description: PGP signature

Re: more detailed description of tup_returned and tup_fetched

[Masahiro Ikeda]

On 2021/05/17 20:46, Fujii Masao wrote:
> 
> 
> On 2021/05/17 18:58, Masahiro Ikeda wrote:
>>
>>
>> On 2021/05/17 15:32, Fujii Masao wrote:
>>>
>>>
>>> On 2021/05/14 17:00, Masahiro Ikeda wrote:
 Hi,

 I worried the difference between "tup_returned" and "tup_fetched" in
 pg_stat_database. I assumed that "tup_returned" means the number of tuples
 that returned to clients. Of course, this is wrong.
>>>
>>> -   Number of rows returned by queries in this database
>>> +   Number of live rows returned by sequential scans of queries in this
>>> database
>>>
>>> -   Number of rows fetched by queries in this database
>>> +   Number of live rows fetched by index scan of queries in this 
>>> database
>>>
>>> I found the following comments in pgstat.h. So maybe even these
>>> new descriptions are incorrect?
>>>
>>>   * Note: for a table, tuples_returned is the number of tuples successfully
>>>   * fetched by heap_getnext, while tuples_fetched is the number of tuples
>>>   * successfully fetched by heap_fetch under the control of bitmap 
>>> indexscans.
>>>   * For an index, tuples_returned is the number of index entries returned by
>>>   * the index AM, while tuples_fetched is the number of tuples successfully
>>>   * fetched by heap_fetch under the control of simple indexscans for this
>>> index.
>>
>> Oh, Thanks!
>>
>> I updated the sentences using the descriptions of
>> "pg_stat_all_tables.seq_tup_read", "pg_stat_all_tables.idx_tup_fetch", and
>> "pg_stat_all_index.idx_tup_read".
>>
>> -   Number of rows returned by queries in this database
>> +   Number of rows returned by queries in this database. The rows
>> correspond to the live rows fetched by sequential scans and index entries
>> returned by scans on indexes
> 
> This is still not correct because this counter is incremented even when
> other scan like TidScan happens?

Sorry, I couldn't find the way to increment tup_returned by TidScan.
Do you mean that Tid Range Scan increments the counter?

Tid Range Scan increments the tup_returned, and
pg_stat_all_tables.seq_tup_read is also incremented. I thought it's ok because
Tid Range Scan is like sequential scan. That's the reason why the document of
pg_stat_all_tables.seq_tup_read says "Number of live rows fetched by
sequential scans"

Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION

Re: Online Documentation Search Issue

[Karoline Pauls]

HAVING is another stop-word.

 Original Message 
On 17 May 2021, 16:43, PG Doc comments form wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/13/functions-comparison.html
> Description:
>
> Hi,
> Just an FYI, but I'm running into a somewhat annoying issue with the
> documentation search that I'm not sure you're aware of.
> Namely, searching for "BETWEEN" (upper or lowercase) yields zero results.
>
> Trying a few different search queries right now, it appears I might be just
> running into an issue where my query is a stopword, but in this case it's
> particularly frustrating because (even once I realize that) there is no
> obvious alternative search query. (I wouldn't have thought to search for
> "Comparison Functions", the page where it's actually explained.)
>
> Is there any way your search platform can be set to index all text that
> appears in the documentation inside 'code' tags? Or could some sort of
> suggestion bar be added to the results page so that if a query contains a
> keyword (especially if it consists entirely of the keyword), a link is
> presented to go to it's page?
>
> Barring that, could searching a stopword trigger a message (and perhaps a
> link to search it on Google) other than just "no results found"?
>
> Thanks,
> Mike

Error building for 64-bit Windows (10)

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/13/install-windows-full.html
Description:

The Solution.pm file has the following lines:
if ($self->{options}->{gss})
{
$proj->AddIncludeDir($self->{options}->{gss} . '\inc\krb5');
$proj->AddLibrary($self->{options}->{gss} . 
'\lib\i386\krb5_32.lib');
$proj->AddLibrary($self->{options}->{gss} .
'\lib\i386\comerr32.lib');
$proj->AddLibrary($self->{options}->{gss} .
'\lib\i386\gssapi32.lib');
}
I had to change them to the following or the compiling failed:
if ($self->{options}->{gss})
{
$proj->AddIncludeDir($self->{options}->{gss} . '\include');
$proj->AddIncludeDir($self->{options}->{gss} . '\include\krb5');
$proj->AddLibrary($self->{options}->{gss} . 
'\lib\amd64\krb5_64.lib');
$proj->AddLibrary($self->{options}->{gss} . 
'\lib\amd64\comerr64.lib');
$proj->AddLibrary($self->{options}->{gss} . 
'\lib\amd64\gssapi64.lib');

Re: [PATCH] fix ICU explorer link in locale documentation

[Magnus Hagander]

On Sun, Apr 4, 2021 at 9:53 AM Anton Voloshin  wrote:
>
> Hello,
>
> Existing Postgres documentation states in doc/src/sgml/charset.sgml:
> The https://ssl.icu-project.org/icu-bin/locexp;>ICU Locale
> Explorer can be used to check the details of a particular locale
> definition.
>
> But the link is broken (SSL certificate does not include
> ssl.icu-project.org as allowed name). Correct link is, I believe,
> https://icu4c-demos.unicode.org/icu-bin/locexp
>
> Attached patch fixes the broken link.

https://icu4c-demos.unicode.org/icu-bin/locexp generates a 404 for me now.

This might be something temporary though, because AFAICT it's where
you end up when you follow the links from the ICU git repo...

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

Re: Where are the legal values for LC_TIME listed?

[Bryn Llewellyn]

t...@sss.pgh.pa.us wrote:

> Bryn wrote:
> 
>> It’s easy to guess values for, say, countries in Europe:
> 
> On Unix-ish systems, "locale -a" should provide the set of available values.  
> We don't attempt to document this because it's so installation-dependent.
> 
>> But what do I use for, say, Simplified Chinese?
> 
> Maybe you don't have a suitable locale installed.
> 
>> The obvious search (LC_TIME in the search box of the PG doc for the current 
>> version) gets no useful hits.
> 
> The main entry for lc_time in
> 
> 19.11.2. Locale and Formatting: 
> https://www.postgresql.org/docs/current/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT
>  
> 
> says “Acceptable values are system-dependent; see Section 23.1 for more 
> information", and if you follow that link, you'll read
> 
>What locales are available on your system under what names depends on what 
> was provided by the operating system vendor and what was
>installed. On most Unix systems, the command `locale -a` will provide a 
> list of available locales.
> 
> Not sure what more we could say.

Thanks for the quick reply, Tom. `locale -a` showed that I do have a suitable 
locale installed. When I add an extra paragraph to my code that starts with 
`set lc_time = 'zh_CN’;`, I get this:

 星期一 / 九月
 一 03- 9-1042 12:00:00.543216 BC

What looks like an m-dash is actually the Chinese character for “one” as in 
“星期一” (lit. “week-one” which is the convention they adopted when they adopted 
the Western Calendar). Had I picked Friday (“星期五”) the output would have been 
nicer.

About “ Not sure what more we could say”, no… I don’t suppose there’s a 
cost-effective next step. In an ideal world, you’d have O/S-dependent code that 
reads the output of `locale -a`, sanitizes it to get the legal arguments for 
`set lc_time`, and presents it as a relation.

My problem is that doc search only gets me so far. Then I have to read each 
whole page from top to bottom to find the nuggets—in this case “ Acceptable 
values are system-dependent”.

Re: Where are the legal values for LC_TIME listed?

[Tom Lane]

Bryn Llewellyn  writes:
> It’s easy to guess values for, say, countries in Europe:

On Unix-ish systems, "locale -a" should provide the set of
available values.  We don't attempt to document this
because it's so installation-dependent.

> But what do I use for, say, Simplified Chinese?

Maybe you don't have a suitable locale installed.

> The obvious search (LC_TIME in the search box of the PG doc for the current 
> version) gets no useful hits.

The main entry for lc_time in

https://www.postgresql.org/docs/current/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT

says "Acceptable values are system-dependent; see Section 23.1 for more
information", and if you follow that link, you'll read

What locales are available on your system under what names depends on
what was provided by the operating system vendor and what was
installed. On most Unix systems, the command locale -a will provide a
list of available locales.

Not sure what more we could say.

regards, tom lane

Where are the legal values for LC_TIME listed?

[Bryn Llewellyn]

It’s easy to guess values for, say, countries in Europe:

This:

create function to_char_demo()
  returns table(z text)
  language plpgsql
as $body$
declare
  -- Counted from midnight 1-Jan-1970 UTC.
  secs   constant double precision not null := 94996756799.456789;
  t  constant timestampnot null := to_timestamp(-secs) at time zone 
'UTC';
  fmt_1  constant text not null := 'TMDay / TMMonth';
  fmt_2  constant text not null := 'TMDy dd-TMMon- 
hh24:mi:ss.us BC';
begin
  set lc_time = 'en_US';
  z := to_char(t, fmt_1);   return next;
  z := to_char(t, fmt_2);   return next;
  z := '';  return next;

  set lc_time = 'it_IT';
  z := to_char(t, fmt_1);   return next;
  z := to_char(t, fmt_2);   return next;
  z := '';  return next;

  set lc_time = 'fi_FI';
  z := to_char(t, fmt_1);   return next;
  z := to_char(t, fmt_2);   return next;
end;
$body$;

select z from to_char_demo();

…brings this result:

 Monday / September
 Mon 03-Sep-1042 12:00:00.543216 BC
 
 Lunedì / Settembre
 Lun 03-Set-1042 12:00:00.543216 BC
 
 Maanantai / Syyskuu
 Ma 03-Syy-1042 12:00:00.543216 BC

But what do I use for, say, Simplified Chinese? Nothing that I guess works. 
And, unlike is the case with “set IntervalStyle”, a bad value doesn’t bring a 
hint (or a doc ref) that gives the LoV.

The obvious search (LC_TIME in the search box of the PG doc for the current 
version) gets no useful hits. Nor does this:

https://www.google.com/search?client=safari=en=LC_TIME+site:https://www.postgresql.org/docs/13/=UTF-8=UTF-8
 

Online Documentation Search Issue

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/13/functions-comparison.html
Description:

Hi,
Just an FYI, but I'm running into a somewhat annoying issue with the
documentation search that I'm not sure you're aware of. 
Namely, searching for "BETWEEN" (upper or lowercase) yields zero results.

Trying a few different search queries right now, it appears I might be just
running into an issue where my query is a stopword, but in this case it's
particularly frustrating because (even once I realize that) there is no
obvious alternative search query. (I wouldn't have thought to search for
"Comparison Functions", the page where it's actually explained.)

Is there any way your search platform can be set to index all text that
appears in the documentation inside 'code' tags? Or could some sort of
suggestion bar be added to the results page so that if a query contains a
keyword (especially if it consists entirely of the keyword), a link is
presented to go to it's page? 

Barring that, could searching a stopword trigger a message (and perhaps a
link to search it on Google) other than just "no results found"?

Thanks,
Mike

Re: more detailed description of tup_returned and tup_fetched

[Fujii Masao]

On 2021/05/17 18:58, Masahiro Ikeda wrote:



On 2021/05/17 15:32, Fujii Masao wrote:



On 2021/05/14 17:00, Masahiro Ikeda wrote:

Hi,

I worried the difference between "tup_returned" and "tup_fetched" in
pg_stat_database. I assumed that "tup_returned" means the number of tuples
that returned to clients. Of course, this is wrong.


-   Number of rows returned by queries in this database
+   Number of live rows returned by sequential scans of queries in this
database

-   Number of rows fetched by queries in this database
+   Number of live rows fetched by index scan of queries in this database

I found the following comments in pgstat.h. So maybe even these
new descriptions are incorrect?

  * Note: for a table, tuples_returned is the number of tuples successfully
  * fetched by heap_getnext, while tuples_fetched is the number of tuples
  * successfully fetched by heap_fetch under the control of bitmap indexscans.
  * For an index, tuples_returned is the number of index entries returned by
  * the index AM, while tuples_fetched is the number of tuples successfully
  * fetched by heap_fetch under the control of simple indexscans for this index.


Oh, Thanks!

I updated the sentences using the descriptions of
"pg_stat_all_tables.seq_tup_read", "pg_stat_all_tables.idx_tup_fetch", and
"pg_stat_all_index.idx_tup_read".

-   Number of rows returned by queries in this database
+   Number of rows returned by queries in this database. The rows
correspond to the live rows fetched by sequential scans and index entries
returned by scans on indexes


This is still not correct because this counter is incremented even when
other scan like TidScan happens?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

doc-fix-for-POSIX-Time-Zone-Specifications

[tanghy.f...@fujitsu.com]

Hi

Attached a patch to delete "CURRENT(as of 2020) " description in POSIX Time 
Zone Specifications.
I'm not a native English speaker, if my fix is not appropriate or insufficient, 
please be kind to share your thought with me.

Regards,
Tang


0001-doc-fix-for-POSIX-Time-Zone-Specifications.patch
Description: 0001-doc-fix-for-POSIX-Time-Zone-Specifications.patch

Re: more detailed description of tup_returned and tup_fetched

[Masahiro Ikeda]

On 2021/05/17 15:32, Fujii Masao wrote:
> 
> 
> On 2021/05/14 17:00, Masahiro Ikeda wrote:
>> Hi,
>>
>> I worried the difference between "tup_returned" and "tup_fetched" in
>> pg_stat_database. I assumed that "tup_returned" means the number of tuples
>> that returned to clients. Of course, this is wrong.
> 
> -   Number of rows returned by queries in this database
> +   Number of live rows returned by sequential scans of queries in this
> database
> 
> -   Number of rows fetched by queries in this database
> +   Number of live rows fetched by index scan of queries in this database
> 
> I found the following comments in pgstat.h. So maybe even these
> new descriptions are incorrect?
> 
>  * Note: for a table, tuples_returned is the number of tuples successfully
>  * fetched by heap_getnext, while tuples_fetched is the number of tuples
>  * successfully fetched by heap_fetch under the control of bitmap indexscans.
>  * For an index, tuples_returned is the number of index entries returned by
>  * the index AM, while tuples_fetched is the number of tuples successfully
>  * fetched by heap_fetch under the control of simple indexscans for this 
> index.

Oh, Thanks!

I updated the sentences using the descriptions of
"pg_stat_all_tables.seq_tup_read", "pg_stat_all_tables.idx_tup_fetch", and
"pg_stat_all_index.idx_tup_read".

-   Number of rows returned by queries in this database
+   Number of rows returned by queries in this database. The rows
correspond to the live rows fetched by sequential scans and index entries
returned by scans on indexes

-   Number of rows fetched by queries in this database
+   Number of rows fetched by queries in this database. The rows
correspond to the live rows fetched by index scans

Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION

Re: more detailed description of tup_returned and tup_fetched

[Fujii Masao]

On 2021/05/14 17:00, Masahiro Ikeda wrote:

Hi,

I worried the difference between "tup_returned" and "tup_fetched" in
pg_stat_database. I assumed that "tup_returned" means the number of tuples
that returned to clients. Of course, this is wrong.


-   Number of rows returned by queries in this database
+   Number of live rows returned by sequential scans of queries in this 
database

-   Number of rows fetched by queries in this database
+   Number of live rows fetched by index scan of queries in this database

I found the following comments in pgstat.h. So maybe even these
new descriptions are incorrect?

 * Note: for a table, tuples_returned is the number of tuples successfully
 * fetched by heap_getnext, while tuples_fetched is the number of tuples
 * successfully fetched by heap_fetch under the control of bitmap indexscans.
 * For an index, tuples_returned is the number of index entries returned by
 * the index AM, while tuples_fetched is the number of tuples successfully
 * fetched by heap_fetch under the control of simple indexscans for this index.

Regards,


--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION