Hi,
The comment of get_collation_name wrote:
* NOTE: since collation name is not unique, be wary of code that uses this
* for anything except preparing error messages.
In file explain.c, the function get_collation_name() is called, but the schema
name won't be outputted.
Since the sche
Hi,
The new version is attached.
Tom Lane wrote:
> I tried to read 0001 but really couldn't make sense of the logic
> at all, because it's seriously underdocumented. At minimum you
> need an API spec comment for canonicalize_path_sub, explaining
> what it's supposed to do and why.
I have adde
Hi
> This patch is a wanted bugfix and has been waiting for an update for 2 months.
>
> Do you plan to send a new version soon?
Yes, I will send a new version before next weekend
Regards
Shenhao Wang
Hi,
I'm developing an extension, after modifying some source file(add some message
like gettext('x')) and execute
> $ make USE_PGXS=1 update-po
> make: Nothing to be done for 'update-po'.
I feel strange because I think *.po.new files should be created.
After some research, I find in $pginst
Hi,
When I work on patch[1] on windows(vs2019), I found there are some
file(generated
by vs2019) are not listed in gitignore.
> $ git status
>
> Untracked files:
> (use "git add ..." to include in what will be committed)
>.vs/
>postgres.vcxproj.user
>src/tools/msvc/bu
Hi,
> -Original Message-
> From: Kyotaro Horiguchi
> Sent: Monday, September 13, 2021 4:36 PM
> To: mich...@paquier.xyz
> Mmm. I haven't thought that so seriously, but '/hoge/foo/bar' doesn't
> seem to be an absolute path on Windows since it lacks
> ":" or "//hostname" part. If we're o
Hi,
> -Original Message-
> From: Andrew Dunstan
> Sent: Thursday, September 9, 2021 8:30 PM
> I think I would say that we should remove any "." or ".." element in the
> path except at the beginning, and in the case of ".." also remove the
> preceding element, unless someone can convince
Hi,
> -Original Message-
> From: Michael Paquier
>
> On Wed, Sep 08, 2021 at 08:54:25AM -0400, Andrew Dunstan wrote:
> > That seems like a bug. It's not very canonical :-)
>
> Yes, better to fix that. I fear that more places are impacted than
> just the tablespace code paths.
> --
> M
Hi,
I find a problem related to tablespace on win32(server2019).
> postgres=# create tablespace tbs location
> 'C:\Users\postgres\postgres_install\aa\..\aa';
> CREATE TABLESPACE
> postgres=# create table tbl(col int) tablespace tbs;
> ERROR: could not stat directory "pg_tblspc/16384/PG_15_20210
Hi,
I find in ecpg.header, the source:
> if (connection)
> if (connection && strcmp(ptr->connection, connection)
> != 0)
The first if statement is useless. And in fix-ecpg-tests.patch:
>- if (connection)
>-
Hi,
I noticed that in v3-0001-Disallow-external-access-to-MaxBackends.patch, there
are some modifications like:
> - for (int i = 0; i <= MaxBackends; i++)
> + for (int i = 0; i <= GetMaxBackends(); i++)
I don't think calling function GetMaxBackends() in the for loop is a
Hi,
Bossart, Nathan wrote:
> I just encountered the same thing, so I am bumping this thread.
Thank you for bumping this thread.
> > I've wondered, independent of this thread, about not making MaxBackends
> > externally visible, and requiring a function call to access it. It should be
> > easier
Hi kuroda-san:
I find another problem about declare statement. The test source looks like:
> EXEC SQL AT con1 DECLARE stmt STATEMENT;
> EXEC SQL PREPARE stmt AS SELECT version();
> EXEC SQL DECLARE cur CURSOR FOR stmt;
> EXEC SQL WHENEVER SQLERROR STOP;
The outout about ecpg:
>test.pgc:14: ERROR:
Hi,
David Steele wrote:
>On 3/26/21 1:20 PM, Magnus Hagander wrote:
>> On Fri, Mar 26, 2021 at 5:52 PM Andrew Dunstan wrote:
>>> On 3/26/21 10:19 AM, David Steele wrote:
> No, the problem is you are using copy/paste and in doing so you are
> *changing'* the value that is being retur
David Steele wrote:
> It's not clear to me what text editors have to do with this? Are you
> editing the file manually?
When I execute SELECT * FROM pg_stop_backup(false, true) in psql.
The results will be shown like:
lsn| labelfile
Hi,
David Steele wrote:
> I'm not sure how I feel about this patch (not really a Windows person)
> but I do think that you shouldn't modify the backup_label when writing
> it, i.e. you should be writing backup_label in binary mode to avoid this
> issue.
IMO, I don't modify backup_lable,
Hi,
I noticed in patch
v58-0001-Add-support-for-apply-at-prepare-time-to-built-i.patch
> +static void
> +prepare_spoolfile_name(char *path, int szpath, Oid subid, char *gid)
> +{
> + PsfHashEntry *hentry;
> +
> + /*
> + * This name is used as the key in the psf_hash HTAB. Therefore
- over 4GB
On Thu, Feb 25, 2021 at 06:07:06AM +, wangsh.f...@fujitsu.com wrote:
> I noticed that this modification only commit into master branch,
> there is still have a problem on 12.6 or 13.2 on Windows.
>
> Do you have a plan to backpatch this commit into REL_12_STABLE or
>
Hi,
I noticed that this modification only commit into master branch,
there is still have a problem on 12.6 or 13.2 on Windows.
Do you have a plan to backpatch this commit into REL_12_STABLE or REL_13_STABLE
?
The commit:
https://github.com/postgres/postgres/commit/bed90759fcbcd72d4d06969eebab8
Hi, Kuroda-san:
Kuroda, Hayato/黒田 隼人 wrote:
> * parse_options() was not refactored because
> it does not affect to parsing the host.
> I will try it if should be.
It seems host only can be the name of server, please refer [1].
And if I use command:
./bin/psql "postgresql://server1:2
Hi, hackers
In [1] wrote:
> If you don't have lcov or prefer text output over an HTML report, you can
> also run
> make coverage
[1] https://www.postgresql.org/docs/13/regress-coverage.html
It seems the lcov is not a necessary program to run a coverage test.
But when I configure with --enable
21 matches
Mail list logo
