Hello devs,
The minor attached patch $SUBJECT, so that it can be inspected easily,
instead of having to look at the source code or whatever.
sh> pgbench --list select-only
-- select-only:
\set aid random(1, 10 * :scale)
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
The
Hello devs,
The attached patch does $SUBJECT, as a showcase for recently added
features, including advanced expressions (CASE...), \if, \gset, ending SQL
commands at ";"...
There is also a small fix to the doc which describes the tpcb-like
implementation but gets one variable name wrong: ba
Hello devs,
A long time ago I submitted a pgbench \into command to store results of
queries into variables independently of the query being processed, which
got turn into \gset (;) and \cset (\;), which got committed, then \cset
was removed because it was not "up to standard", as it could not
Hello,
Thanks for the feedback.
I have one minor observation that in case of initDropTables you log
'drop' and in case of initCreateTables you log 'create table'. We need
to be consistent. The "drop tables" and "create tables" are the best
fit here.
Ok.
Attached version does that, plus avoi
Hello devs,
I'm looking at psql's use of PQexec for implementing some feature.
When running with multiple SQL commands, the doc is not very helpful.
From the source code I gathered that PQexec returns the first COPY results
if any, and if not the last non-empty results, unless all is empty in
Hello Alvaro,
I'm looking at psql's use of PQexec for implementing some feature.
When running with multiple SQL commands, the doc is not very helpful.
From the source code I gathered that PQexec returns the first COPY results
if any, and if not the last non-empty results, unless all is empty
Hello devs,
The attached patch implements a new SHOW_ALL_RESULTS option for psql,
which shows all results of a combined query (\;) instead of only the last
one.
This solves a frustration that intermediate results were hidden from view
for no good reason that I could think of.
For that, ca
This is not the problem only for pg_test_timing. If you want to
address this, the patch needs to cover all the client commands
like psql, createuser. I'm not sure if it's worth doing that.
I think it might be an actively bad idea. There's a pretty
widespread convention that "--" is a no-op s
Hello Tom,
We've generally felt that deferring to the behavior of the platform's
getopt() or getopt_long() is a better idea than trying to enforce some
lowest-common-denominator version of switch parsing, on the theory that
users of a given platform will be used to whatever its getopt does.
Th
Hello Tom,
Fix unportable code in pgbench.
Sorry for this unforseen issue... portability is a pain:-(
The buildfarm points out that UINT64_FORMAT might not work with sscanf;
it's calibrated for our printf implementation, which might not agree
with the platform-supplied sscanf. Fall back t
Hello Tom,
Yep, but ISTM that it is down to 32 bits,
Only on 32-bit-long machines, which are a dwindling minority (except
for Windows, which I don't really care about).
So the third short is now always 0. Hmmm. I'll propose another option over
the week-end.
I suppose we could put pg_strt
As usual, it is better with the attachement. Sorry for the noise.
Yep, but ISTM that it is down to 32 bits,
Only on 32-bit-long machines, which are a dwindling minority (except
for Windows, which I don't really care about).
So the third short is now always 0. Hmmm. I'll propose another opti
Hello Nikita,
Attached patches add missing distance operator <->(box, point).
Indeed.
We already have reverse operator <->(point, box), but it can't be used
for kNN search in GiST and SP-GiST. GiST and SP-GiST now support kNN
searches over more complex polygons and circles, but do not su
Hello,
I want to add a feature in PostgreSQL, and I need use map structure and
set structure(like STL in C++). Do PostgreSQL have realized these
structures? Where can I find the functions? What I need in the code is
just like this: map>, set
You are looking for a hash table, see under "src
Any interest in this?
Yep, although I'm not sure of the suggested command name. More
suggestions:
\stderr ...
\err ...
\error ...
\warn ...
\warning ...
--
Fabien.
Hello Corey,
\warn ...
\warning ...
These two seem about the best to me, drawing from the perl warn command.
Yep, I was thinking of perl & gmake. Maybe the 4 letter option is better
because its the same length as "echo".
I suppose we could go the bash &2 route here, but I don't w
Bonjour Daniel,
When FETCH_COUNT is set, queries combined in a single request don't work
as expected:
\set FETCH_COUNT 10
select pg_sleep(2) \; select 1;
No result is displayed, the pg_sleep(2) is not run, and no error
is shown. That's disconcerting.
Indeed.
Does anyone have thoughts abo
\warn ...
\warning ...
These two seem about the best to me, drawing from the perl warn command.
Yep, I was thinking of perl & gmake. Maybe the 4 letter option is better
because its the same length as "echo".
I suppose we could go the bash &2 route here, but I don't want to.
I agre
Hello David,
I noticed that there wasn't a bulk way to see table logged-ness in psql,
so I made it part of \dt+.
Applies, compiles, works for me.
ISTM That temporary-ness is not shown either. Maybe the persistence column
should be shown as is?
Also I'd suggest that the column should be d
Hello Tom,
Keep in mind that a large part of the reason why the \cset patch got
bounced was exactly that its detection of \; was impossibly ugly
and broken. Don't expect another patch using the same logic to
get looked on more favorably.
Although I do not claim that my implementation was ve
Keep in mind that a large part of the reason why the \cset patch got
bounced was exactly that its detection of \; was impossibly ugly
and broken. Don't expect another patch using the same logic to
get looked on more favorably.
Looking at the end of the discussion about \cset, it seems what
y
Hello David,
I noticed that there wasn't a bulk way to see table logged-ness in psql,
so I made it part of \dt+.
Applies, compiles, works for me.
ISTM That temporary-ness is not shown either. Maybe the persistence column
should be shown as is?
Temporariness added, but not raw.
Ok, it is
Hello Aya-san,
Thanks for this review.
There is space (+--' '). Please delete it. It is cause of regression test
failed.
Indeed, unsure how I could do that. Fixed.
IMHO this new setting should be on by default: few people know about \; so
it would not change anything for most, and I do no
Hello David,
Patch v3 applies, but compiles for me with a warning because the
indentation of the following size block has been changed:
describe.c: In function ‘listTables’:
describe.c:3705:7: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
else if (pset.sversion >=
Hello David,
Please find attached v2, name is now \warn.
Patch applies cleanly, compiles, "make check ok", although there are no
tests. Doc gen ok.
Code is pretty straightforward.
I'd put the commands in alphabetical order (echo, qecho, warn) instead of
e/w/q in the condition.
The -n t
Hello David,
About v3. Applies, compiles, global & local make check are ok. doc gen ok.
I'd put the commands in alphabetical order (echo, qecho, warn) instead of
e/w/q in the condition.
Done.
Cannot see it:
+ else if (strcmp(cmd, "echo") == 0 || strcmp(cmd, "warn") == 0 || strcmp(cmd,
Hello David,
Patch applies. There seems to be a compilation issue:
describe.c:5974:1: error: expected declaration or statement at end of
input
}
Also there is an added indentation problem: the size & description stuff
have been moved left but it should still in the verbose case, and a } i
Hello David,
About v4: applies, compiles, global & local "make check" ok. Doc gen ok.
Code & help look ok.
About the doc: I do not understand why the small program listing contains
an "\echo :variable". Also, the new entry should probably be between the
\w & \watch entries instead of betwee
Hello David,
Patch applies. There seems to be a compilation issue:
describe.c:5974:1: error: expected declaration or statement at end of
input
}
This is in brown paper bag territory. Fixed.
I do not understand why you move both size and description out of the
verbose mode, it should
Hello David,
About v5: applies, compiles, global & local make check ok, doc gen ok.
Very minor comment: \qecho is just before \o in the embedded help, where
it should be just after. Sorry I did not see it on the preceding
submission.
--
Fabien.
Hello David,
My mistake. Fixed.
About v6: applies, compiles, make check ok.
Code is ok.
Maybe there could be a comment to tell that prior version are not
addressed, something like:
...
}
/* else do not bother guessing the temporary status on old version */
No tests, pending an a
Hello David,
About v5: applies, compiles, global & local make check ok, doc gen ok.
Very minor comment: \qecho is just before \o in the embedded help, where it
should be just after. Sorry I did not see it on the preceding submission.
Done.
Patch v6 applies, compiles, global & local make c
Hello David,
Patch v7 applies, compiles, make check ok. No docs needed.
No tests, pending some TAP infrastructure.
I could no test with a version between 8.4 & 9.1.
No further comments. Marked as ready.
--
Fabien.
Hello devs,
On my SSD Ubuntu laptop, with postgres-distributed binaries and unmodified
default settings using local connections:
## pg 11.2
> time pgbench -i -s 100
...
done in 31.51 s
# (drop tables 0.00 s, create tables 0.01 s, generate 21.30 s, vacuum 3.32 s,
primary keys 6.88
Hello Andres,
## pg 11.2 done in 31.51 s
## pg 12devel (cd3e2746) real0m38.695s
What change could explain such a significant performance regression?
I think the pre-release packages have had assertions enabled at some
point. I suggest checking that. If it's not that, profiles would
About v5: applies, compiles, global & local make check ok, doc gen ok.
Very minor comment: \qecho is just before \o in the embedded help,
where it should be just after. Sorry I did not see it on the preceding
submission.
Unfortunately new TAP test doesn't pass on my machine. I'm not good a
Hello Andres,
The effect is that the first generation seems to take more time, but
dropping the table and regenerating again much less, with a typical 40%
performance improvement between first and second run, independently of the
version. The reported figures above where comparisons between fi
I guess that you have a verbose ~/.psqlrc.
Can you try with adding -X to psql option when calling psql from the tap
test?
Ah, true. This patch works for me:
diff --git a/src/bin/psql/t/001_psql.pl b/src/bin/psql/t/001_psql.pl
index 32dd43279b..637baa94c9 100644
--- a/src/bin/psql/t/001_psql
Hello,
Patch looks good to me, and work fine on my machine. One minor
observation is option 'list' mostly used to list the elements like
"pgbench -b list" shows the available builtin scripts. Therefore we
should use a word which seems to be more relevant like --show-script.
Thanks for the r
Now the patch is good now.
The new status of this patch is: Ready for Committer
Ok, thanks.
--
Fabien.
Er, ping. Nobody has reviewed the latest patchs.
Next CF is in July, two months away.
You might consider reviewing other people patches, that is expected to
make the overall process work. There are several documentation or
comment patches in the queue.
--
Fabien.
Hello Bruce,
I have posted a draft copy of the PG 12 release notes here:
http://momjian.us/pgsql_docs/release-12.html
They are committed to git. It includes links to the main docs, where
appropriate. Our official developer docs will rebuild in a few hours.
Pgbench entry "Improve
Bonjour Daniel,
IMHO this new setting should be on by default: few people know about \; so
it would not change anything for most, and I do not see why those who use
it would not be interested by the results of all the queries they asked for.
I agree with your opinion.
Ok. I did not yet chan
Re-bonjour Daniel,
This attached version does:
- ensure that warnings appear just before its
- add the entry in psql's help
- redefine the function boundary so that timing is cleaner
- include somehow improved tests
\errverbose seems to no longer work with the patch:
Here is a v3 which
V2 is a rebase.
A long time ago I submitted a pgbench \into command to store results of
queries into variables independently of the query being processed, which got
turn into \gset (;) and \cset (\;), which got committed, then \cset was
removed because it was not "up to standard", as it could
V11 is just a rebase after the reindentation patches.
Indeed, yet again, I forgot the attachement:-(
I stared at the new test case for a while, and I must say it looks very
cryptic. It's not exactly this patch's fault - all the pgbench tests are
cryptic -
Perl is cryptic. Regexprs are cryp
successfully and the tests passed without
problems.
So, I think the latest patch is fine.
Best regards,
On 3/3/19 12:55 PM, Fabien COELHO wrote:
Indeed, the patch needs a rebase & conflit resolution. I'll do it. Later.
Here is an update:
- take advantage of pg_bitutils (althoug
Here is a v3 which fixes \errverbose, hopefully.
V5 is a rebase and an slightly improved documentation.
--
Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index b86764003d..4a1b562f24 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-r
Although I agree it is not worth a lot of trouble, and even if I don't do
Windows, I think it valuable that the behavior is the same on all platform.
The attached match shares pg_str2*int64 functions between frontend and
backend by moving them to "common/", which avoids some code duplication.
In example of random_zipfian, the explanation is "which itself(2) is
produced (3/2)*2.5 = 2.76 times more frequently than 3".
"(3/2)*2.5 = 2.76" is wrong. The correct expression is "(3/2)**2.5 = 2.76".
Indeed. Attached patch to fix this typo.
--
Fabiendiff --git a/doc/src/sgml/ref/pgbench.sg
Subject: Why does pg_checksums -r not have a long option?
Was this just forgotten?
Probably? Attached a patch.
--
Fabien.diff --git a/doc/src/sgml/ref/pg_checksums.sgml b/doc/src/sgml/ref/pg_checksums.sgml
index a0ffeb0ab0..5549ea679a 100644
--- a/doc/src/sgml/ref/pg_checksums.sgml
+++ b/doc
Hello Michael-san,
No objections with adding a long option for that stuff. But I do have
an objection with the naming because we have another tool able to work
on relfilenodes:
$ oid2name --help | grep FILE
-f, --filenode=FILENODEshow info for table with given file node
In this case, lon
Bonjour Michael,
+
+ -f filenode
+
--filenode=filenode
+
+
+Only validate checksums in the relation with specified relation file
node.
+
Two nits. I would just have been careful about the number of
characters in the line within the markup. And we
|I have no problem with changing it to -r. -f seems a bit wrong to me,
|as it might read as a file. And in the future we might want to implement
|the ability to take full filename (with path), in which case it would
|make sense to use -f for that.
You could also use a long option for that with
Hello Peter,
The abort is by a client, but the code seems to only check the first
client of a thread. ISTM that if the second or later client abort it may
not be detected? Probably an intermediate aggregation at the thread level
is needed, or maybe a global variable, or as errors are counted so
Hello Andrew,
A question: would it makes sense to have a symmetrical
--include-database=PATTERN option as well?
I don't think so. If you only want a few databases, just use pg_dump. The
premise of pg_dumpall is that you want all of them and this switch provides
for exceptions to that.
Ok
Hello Kirk,
I have decided to take a look into this patch.
Thanks for the feedback.
I noticed in your refactored code that CSTATE_CHOOSE_SCRIPT may now also
change to CSTATE_FINISHED when timer is exceeded. (Before, it only
changes to either CSTATE_START_THROTTLE or CSTATE_START_TX) But th
Hello Hironobu-san,
I reviewed pgbench-prp-func-6.patch.
Thanks.
(1) modular_multiply()
In modular_multiply(), the numbers of digits of inputs are checked in order
to determine using the interleaved modular multiplication algorithm or not.
However, the check condition absolutely depends o
Here is yet another rebase.
Here is yet another rebase after Peter's exit status changes on pgbench.
Whether Stephen will have time to commit this patch is unclear. I'd suggest
that I remove his name from the committer column so that another committer
may consider it.
What do you think?
Hello Michaël,
The first failure is unrelated to the involved commits, as they touched
completely different areas of the code:
INSERT INTO hash_split_heap SELECT a/2 FROM generate_series(1, 25000) a;
+ WARNING: buffer refcount leak: [6481] (rel=base/16384/32349, blockNum=156,
flags=0x938
Hello Arthur,
sh> psql "host=127.0.0.2 hostaddr=127.0.0.1"
I'm not sure that is is the issue. User defined the host name and psql
show it.
The issue is that "host" is an ip, "\conninfo" will inform wrongly that you
are connected to "127.0.0.2", but the actual connection is really to
"127.
Hello Tom & Amit,
Both animals use gcc experimental versions, which may rather underline a
new bug in gcc head rather than an existing issue in pg. Or not.
It is possible, but what could be the possible theory?
It seems like the two feasible theories are (1) gcc bug, or (2) buffer
leak th
Hello Hironobu-san,
In pseudorandom_perm(), `modular_multiply() + (key >> LCG_SHIFT)` may
overflow if the result of modular_multiply() is large. Therefore, I've
improved it.
Also, I've simplified Step 5 in modular_multiply().
Attached is a v10, where I have:
- updated some comments
- th
I thinks this patch is fine.
Thanks!
Hopefully some committer will pick it up at some point.
--
Fabien.
Hello Alvaro,
Can you please pgindent this?
Hmmm. After some investigation, I installed some "pg_bsd_indent" and ran
the "pgindent" script, which reindented far more than the patch... So I
picked up the patch-related changes and integrated them manually, although
not comment changes which
Hello Alvaro,
although not comment changes which break the logic of the algorithm
descriptions. I have not found how to tell pgindent to let comments
indentation alone.
You can use /*- for such comments.
Thanks for the hint. Here is an updated patch using this marker.
I noticed that so
Hallo Michael,
New version 5 attached.
Patch does not seem to apply anymore.
Moreover, ISTM that some discussions about behavioral changes are not
fully settled.
My current opinion is that when offline some errors are not admissible,
whereas the same errors are admissible when online be
Hello Robert,
I think this patch is a solution in search of a problem.
I take note of this negative opinion.
[...] It's true that the above example is very confusing, but there's no
reason for everybody to ever do that.
If you do it, even by accident, there is no way to guess what is wro
Hello Robert,
[...] that's a self-inflicted injury.
Sure. I'm trying to be more user friendly.
It's not that I am opposed to helping people avoid self-inflicted
injuries, but this one doesn't seem either likely or serious.
If I'm trying to improve something, I tend to be thorough about it
Hello,
This is a follow-up to another patch I posted about libpq confusing
documentation & psql resulting behavior under host/hostaddr settings.
Although the first mostly documentation patch did not gather much
enthousiasm, I still think both issues deserve a fix.
About updating psql's beh
Hello Jeff,
I suspect the easiest thing to narrow it down would be to bisect the
problem in gcc :(
Their commit r265241 is what broke the PostgreSQL build. It also broke the
compiler itself--at that commit it was no longer possible to build itself.
I had to --disable-bootstrap in order to g
Hallå Daniel,
Checking for conflicting options in pg_restore was mostly done in main() with
one check deferred until RestoreArchive(). Reading the git history makes it
seem like it simply happened, without the disjoint checking being intentional.
Am I reading it right that we can consolidate a
Hello Narayanan,
There is a possible catch:
Function RestoreArchive is called both from pg_dump & pg_restore, so now
the sanity check is not performed for the former (which does not have the
-1 option, though). Moreover, the function is noted "Public", which may
suggest that external tools co
Hallå Daniel,
an assertion?
v2 applies, compiles, both local & global make check are ok.
Its CF category could have been "bug fix" or "restructuring".
[...] Perhaps, we don’t really test for all other potential
misconfigurations of the options so I can go either way. It’s also a
cheap en
Hello Pavel,
I try to create operator + for varchar and integer with Oracle behave.
create or replace function sum(varchar, int)
returns int as $$ select $1::int + $2 $$ language sql;
create operator + (function = sum, leftarg = varchar, rightarg = int,
commutator = +);
create table foo2(a
Hello Tatsuo-san,
pgbench doc (and some comments in pgbench.c) regarding "-M prepared"
option is not quite correct. [...] Actually "extended" mode uses
prepared statements too.
Ok, I understand that you mean that PQsendQueryParams uses an unamed query
internally to separate parsing & execu
Hallo Michael,
Patch v6 applies cleanly, compiles, local make check is ok.
My current opinion is that when offline some errors are not admissible,
whereas the same errors are admissible when online because they may be due
to the ongoing database processing, so the behavior should not be stric
Hello Andrew,
This patch addresses all these concerns.
Patch v4 applies cleanly, compiles, doc generation ok, global & local
tests ok.
Tiny comments: there is a useless added blank line at the beginning of the
added varlistenry.
I have recreated the CF entry and put the patch to ready.
:-( My fault, I just created a new one.
Hmmm... so did I:-) We did it a few minutes apart. I did not find yours
when I first searched, then I proceeded to try to move the previous CF
entry which had been marked as "returned" but this was rejected, so I
recreated the one without checking whe
Their commit r265375 fixed the ability to compile itself, but built
PostgreSQL binaries remain broken there and thereafter.
|...]
Thanks a lot for this investigation! I can fill in a gcc bug report. There
would be a enormous work to narrow it down to a small test case, it is
unclear how they
I don't know enough about the app internals to comment. But it probably
shouldn't appear in the stats, or else should have its own category in the
stats.
Or that's closer to "Rejected by the author himself"? "Withdrawn"
sounds like a good term for that, we surely don't want to simply remove
Robert,
Yes, you need to send params (thus send bind message) anyway.
Regarding re-parsing, maybe you mixed up parse-analythis with
planning? Re-parse-analythis can only be avoided if you can reuse
named (or unnamed) parepared statements.
So given this, I'm struggling to see anything wrong w
Bonjour Michaël,
Because the same patch submission is already counted? It is a rare
occurence, so just a "Withdrawn" state could be enough, and slightly false
CF stats are no big deal.
Or as we are dealing with duplicated entries, perhaps we could just
delete the entry not wanted, which seems
Hello Tatsuo-san,
While playing with pgbench, I found multiple "-M query_mode" can be
set more than once.
As already said by others, the "last one win" is somehow a useful feature,
so I'd prefer avoiding erroring out on this one.
This could leave:
(1) improving pgbench doc by spelling ou
Bonjour Daniel,
Here's a rebased version with a couple regression tests
added per the discussions during the previous CF.
Now at https://commitfest.postgresql.org/20/1861/
Patch applies cleanly, compiles, make check ok, doc gen ok.
Fine with me. I switched the patch to "Ready".
--
Fabien.
"prepared: use extended query protocol with reused prepared statements"
I don't think this mouthful is useful in the --help output. The
existing wording gets the message across just fine, I think. More
details can be put in the reference page.
These suggestions are for the online doc page
Thanks for your remarks and advices, and of course for your help to
rewrite the text.
So, it is now included in the new version attached.
I hope it will be ok this time.
At least it looks ok to me.
Patch applies cleanly, doc build ok.
I've put the patch as "Ready".
--
Fabien.
The patch attached add additional option for multi values insert statement
with a default values of 100 row per statement so the row lose during error
is at most 100 rather than entire table.
Patch does not seem to apply anymore, could you rebase?
--
Fabien.
Hello Peter,
Attached is a rebased patch set. No functionality changes.
Patch applies cleanly, compile, global make check ok, doc gen ok.
Shouldn't psql tab completion be updated as well?
About the code:
I must admit that do not like much the three global variables &
Save/Restore functio
Hello Ryohei,
I'd like to suggest introducing two parameters to handle client-server
communication timeouts.
I'm generally fine with giving more access to low-level parameters to
users. However, I'm not sure I understand the use case you have that needs
these new extensions.
"socket_tim
Bonjour Michaël,
First, it seems to me that it is necessary to overcomplicate the
interface of psql for that. Most of the other formats don't have their
own switch, and it is perfectly possible to use CSV format with just
--pset=format=csv.
Although this work, it is not very user friendly no
Hello Robert,
psql> \conninfo
You are connected to database "fabien" as user "fabien" on host "foo" at port
"5432".
I remain of the opinion that this is not a bug. You told it that foo
has address 127.0.0.1 and it believed you; that's YOUR fault.
Hmmm. For me, if a user asks \conninfo
Bonjour Michaël,
But again COPY is concerned with importing the data that preexists,
even if it's weird, whereas a psql output formats are not.
Hm. I checked the contents of the patch in details which provide output
consistent with COPY, but after looking at the global picture I am
getting c
Hello Alvaro,
Thanks for having a look at this patch.
Think of one initialization followed by two appends:
SELECT 1 AS x \cset
SELECT 2 \; SELECT 3 AS y \cset
SELECT 4 \; SELECT 5 \; SELECT 6 AS z \gset
In the end, we must have the full 6 queries
"SELECT 1 AS x \; SELECT 2 \; SELECT
I think this patch's Command->lines would benefit from using PQExpBuffer
(or maybe StringInfo?) for the command string instead of open-coding
string manipulation and allocation.
Indeed it could be used, but it is not used anywhere in "pgbench": not for
lines, not for variable subtitutions, n
Attached is a v3, where I have updated inaccurate comments.
Attached v4 is a rebase after 409231919443984635b7ae9b7e2e261ab984eb1e
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 73d3de0677..ed6ff75426 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgb
On Sat, 17 Nov 2018, Alvaro Herrera wrote:
/* --
* getHostaddr -
* Fills 'host_addr' with the string representation of the currently connected
* socket in 'conn'.
* --
*/
static void
getHostaddr(PGconn *conn, char *host_addr, int host_addr_len)
Fabien, are you planning
Fabien, are you planning to fix things per Arthur's review?
Yep, I am.
I will not do the above though, because the PQgetHostaddr API would differ
from all other connection status functions (PQgetHost, PQgetUser...) which
are all "char * PQget(PGconn * conn)"
Sorry, I'm mixing everything,
Hello Pavel,
I think so some redundant messages can be reduced - see function
printConnInfo - attached patch
I thought about doing like that, but I made the debatable choice to keep
the existing redundancy because it minimizes diffs and having a
print-to-stdout special function does not lo
I think so some redundant messages can be reduced - see function
printConnInfo - attached patch
I thought about doing like that, but I made the debatable choice to keep the
existing redundancy because it minimizes diffs and having a print-to-stdout
special function does not look like a very c
501 - 600 of 1351 matches
Mail list logo
