On Wed, Sep 18, 2019 at 10:13:20AM +0900, Michael Paquier wrote:
> As of now, here is an updated patch which takes the path to not
> complicate the refactored APIs and fixes the issue with queryID in
> readfuncs.c. Thoughts?
For now, and seeing that there is little interest in it. I have
marked
On Fri, Oct 04, 2019 at 02:27:44PM +0530, Ashutosh Sharma wrote:
> Is there any specific reason for hard coding the *base* of a number
> representing the string in strtouint64(). I understand that currently
> strtouint64() is being used just to convert an input string to decimal
> unsigned value bu
On Fri, Oct 4, 2019 at 8:58 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-10-04 14:27:44 +0530, Ashutosh Sharma wrote:
> > Is there any specific reason for hard coding the *base* of a number
> > representing the string in strtouint64(). I understand that currently
> > strtouint64() is being used jus
Hi,
On 2019-10-04 14:27:44 +0530, Ashutosh Sharma wrote:
> Is there any specific reason for hard coding the *base* of a number
> representing the string in strtouint64(). I understand that currently
> strtouint64() is being used just to convert an input string to decimal
> unsigned value but what
Is there any specific reason for hard coding the *base* of a number
representing the string in strtouint64(). I understand that currently
strtouint64() is being used just to convert an input string to decimal
unsigned value but what if we want it to be used for hexadecimal
values or may be some oth
On Tue, Sep 17, 2019 at 11:29:13AM +0900, Michael Paquier wrote:
> In order to unify the parsing interface and put all the conversion
> routines in a single place, I still think that the patch has value so
> I would still keep it (with a fix for the queryId parsing of course),
> but there is much m
On Tue, Sep 17, 2019 at 11:29:13AM +0900, Michael Paquier wrote:
> The code paths of the patch calling pg_strtouint64_check to parse
> completion tags (spi.c and pg_stat_statements.c) should complain in
> those cases as the format of the tags for SELECT and COPY is fixed.
>
> In order to unify the
On Mon, Sep 16, 2019 at 10:08:19AM -0700, Andres Freund wrote:
> On 2019-09-14 15:02:36 +0900, Michael Paquier wrote:
>> - Switching OID to use pg_strtoint32 causes a failure with initdb.
>
> Needs to be debugged too. Although I suspect this might just be that you
> need to use unsigned variant.
Bonjour Michaël,
Otherwise, this batch of changes looks ok to me.
Thanks.
About v15: applies cleanly, compiles, "make check" ok.
While re-reading the patch, there are bit of repetitions on pg_strtou?int*
comments. I'm wondering whether it would make sense to write a global
comments befor
Hi,
On 2019-09-14 15:02:36 +0900, Michael Paquier wrote:
> On Fri, Sep 13, 2019 at 06:38:31PM -0700, Andres Freund wrote:
> > On 2019-09-10 12:05:25 +0900, Michael Paquier wrote:
> >> On Mon, Sep 09, 2019 at 05:27:04AM -0700, Andres Freund wrote:
> >> Attached is an updated patch? How does it loo
On Sat, Sep 14, 2019 at 10:24:10AM +0200, Fabien COELHO wrote:
> It should rather call pg_strtoint16? And possibly switch the "short int"
> declaration to int16?
Sure, but you get into other problems if using the 16-bit version for
some other fields, which is why it seems to me that we should add
Bonjour Michaël,
- Switching INT to use pg_strtoint32() causes a set of warnings as for
example with AttrNumber:
72 | (void) pg_strtoint32(token, &local_node->fldname)
| ^
| |
| Att
On Fri, Sep 13, 2019 at 06:38:31PM -0700, Andres Freund wrote:
> On 2019-09-10 12:05:25 +0900, Michael Paquier wrote:
>> On Mon, Sep 09, 2019 at 05:27:04AM -0700, Andres Freund wrote:
>> Attached is an updated patch? How does it look? I have left the
>> parts of readfuncs.c for now as there are m
On 2019-09-10 12:05:25 +0900, Michael Paquier wrote:
> On Mon, Sep 09, 2019 at 05:27:04AM -0700, Andres Freund wrote:
> > On 2019-09-09 20:57:46 +0900, Michael Paquier wrote:
> > But ISTM all of them ought to just use the C types, rather than the SQL
> > types however. Since in the above proposal t
On Tue, Sep 10, 2019 at 12:05:25PM +0900, Michael Paquier wrote:
> Attached is an updated patch? How does it look? I have left the
> parts of readfuncs.c for now as there are more issues behind that than
> doing a single switch, short reads are one, long reads a second. And
> the patch already d
On Mon, Sep 09, 2019 at 05:27:04AM -0700, Andres Freund wrote:
> On 2019-09-09 20:57:46 +0900, Michael Paquier wrote:
> But ISTM all of them ought to just use the C types, rather than the SQL
> types however. Since in the above proposal the caller determines the
> type names, if you want a differen
On Mon, Sep 09, 2019 at 03:17:38AM -0700, Andres Freund wrote:
> On 2019-09-09 14:28:14 +0900, Michael Paquier wrote:
>> @@ -80,7 +81,7 @@
>> #define READ_UINT64_FIELD(fldname) \
>> token = pg_strtok(&length); /* skip :fldname */ \
>> token = pg_strtok(&length); /
Hi,
On 2019-09-09 20:57:46 +0900, Michael Paquier wrote:
> > I don't really buy that saving a few copies of a strings is worth that
> > much. But if you really want to do that, the right approach imo would be
> > to move the error reporting into a separate function. I.e. something
> >
> > void pg
On Mon, Sep 09, 2019 at 03:17:38AM -0700, Andres Freund wrote:
> On 2019-09-09 14:28:14 +0900, Michael Paquier wrote:
> I *VEHEMENTLY* oppose the introduction of any future pseudo-generic
> routines taking the type width as a parameter. They're weakening the
> type system and they're unnecessarily
Hi,
On 2019-09-09 14:28:14 +0900, Michael Paquier wrote:
> On Thu, Sep 05, 2019 at 03:52:48PM +0900, Michael Paquier wrote:
> > Right, there was this part. This brings also the point of having one
> > interface for the backend as all the error messages for the backend
> > are actually the same, w
On Thu, Sep 05, 2019 at 03:52:48PM +0900, Michael Paquier wrote:
> Right, there was this part. This brings also the point of having one
> interface for the backend as all the error messages for the backend
> are actually the same, with the most simple name being that:
> pg_strtoint(value, size, er
On Wed, Sep 04, 2019 at 12:49:17PM +0200, Fabien COELHO wrote:
> From a compiler perspective, the (un)likely tip is potentially useful on any
> test. We know when parsing a that it is very unlikely that the string
> conversion would fail, so we can tell that, so that the compiler knows which
> bran
On Wed, Sep 04, 2019 at 02:08:39AM -0700, Andres Freund wrote:
>> +static bool
>> +str2int64(const char *str, int64 *val)
>> +{
>> +pg_strtoint_status stat = pg_strtoint64(str, val);
>> +
>
> I find it weird to have a wrapper that's named 'str2...' that then calls
> 'strto' to imp
Bonjour Michaël,
Attached a rebased version which implements the int64/uint64 stuff. It is
basically the previous patch without the overflow inlined functions.
- if (!strtoint64(yytext, true, &yylval->ival))
+ if (unlikely(pg_strtoint64(yytext, &yylval->ival) != PG_STRTOINT_OK))
It
Hi,
On 2019-09-03 20:10:37 +0200, Fabien COELHO wrote:
> @@ -113,7 +113,7 @@ parse_output_parameters(List *options, uint32
> *protocol_version,
>errmsg("conflicting or
> redundant options")));
> protocol_version_given = true;
On Tue, Sep 03, 2019 at 08:10:37PM +0200, Fabien COELHO wrote:
> Attached a rebased version which implements the int64/uint64 stuff. It is
> basically the previous patch without the overflow inlined functions.
- if (!strtoint64(yytext, true, &yylval->ival))
+ if (unlikely(pg_strtoint64(yyt
This part has been committed, now let's move to the next parts of your
patch.
Attached a rebased version which implements the int64/uint64 stuff. It is
basically the previous patch without the overflow inlined functions.
--
Fabien Coelho - CRI, MINES ParisTechdiff --git a/contrib/pg_stat_st
On Sun, Sep 01, 2019 at 08:07:06PM +0200, Fabien COELHO wrote:
> They allow to quickly do performance tests, for me it is useful to keep it
> around, but you are the committer, you do as you feel.
If there are more voices for having that in core, we could consider
it. For now I have added that in
Michaël,
I would put back unlikely() on overflow tests, as there are indeed unlikely
to occur and it may help some compilers, and cannot be harmful. It also
helps the code reader to know that these path are not expected to be taken
often.
Hm. I don't agree about that part, and the original s
On Sun, Sep 01, 2019 at 01:57:06PM +0200, Fabien COELHO wrote:
> I would put back unlikely() on overflow tests, as there are indeed unlikely
> to occur and it may help some compilers, and cannot be harmful. It also
> helps the code reader to know that these path are not expected to be taken
> often
Bonjour Michaël,
You are right as well that having symmetry with the signed methods is
much better. In order to see the difference, you can just do that with
the extension attached, after of course hijacking int.h with some undefs
and recompiling the backend and the module: select
pg_overfl
On Fri, Aug 30, 2019 at 04:50:21PM +0200, Fabien COELHO wrote:
> Given the overheads of the SQL interpreter, I'm unsure about what you would
> measure at the SQL level. You could just write a small standalone C program
> to test perf and accuracy. Maybe this is what you have in mind.
After a certa
Michaël,
For symmetry and efficiency, ISTM that uint16 mul overflow could use uint32
and uint32 could use uint64, and the division-based method be dropped in
these cases.
Yes, the division would be worse than the other. What do you think
about using the previous module I sent and measure how
On Fri, Aug 30, 2019 at 10:06:11AM +0200, Fabien COELHO wrote:
> Patch applies cleanly, compiles, "make check" ok, but the added functions
> are not used (yet).
Thanks.
> I think that factoring out comments is a good move.
>
> For symmetry and efficiency, ISTM that uint16 mul overflow could use
Michaël,
attached is a first cut that I would like to commit separately which
adds all the compatibility overflow routines to int.h for uint16, uint32
and uint64 with all the fallback implementations (int128-based method
added as well if available). I have also grouped at the top of the file
On Thu, Aug 29, 2019 at 08:14:54AM +0200, Fabien COELHO wrote:
> Attached v7 does create uint64 overflow inline functions. The stuff yet is
> not moved to "common/int.c", a file which does not exists, even if
> "common/int.h" does.
Thanks for the new version. I have begun reviewing your patch, an
Bonjour Michaël,
- *ptr && WHATEVER(*ptr)
*ptr is redundant, WHATEVER yields false on '\0', and it costs on each
char but at the end. It might be debatable in some places, e.g. it is
likely that there are no spaces in the string, but likely that there are
more than one digit.
Still t
On Wed, Aug 28, 2019 at 09:50:44AM +0200, Fabien COELHO wrote:
> - *ptr && WHATEVER(*ptr)
> *ptr is redundant, WHATEVER yields false on '\0', and it costs on each
> char but at the end. It might be debatable in some places, e.g. it is
> likely that there are no spaces in the string, but like
Michaël,
I have taken the liberty to optimize the existing int64 function by removing
spurious tests.
Which are?
- *ptr && WHATEVER(*ptr)
*ptr is redundant, WHATEVER yields false on '\0', and it costs on each
char but at the end. It might be debatable in some places, e.g. it is
likel
On Wed, Aug 28, 2019 at 08:51:29AM +0200, Fabien COELHO wrote:
> Here is an updated patch for the u?int64 conversion functions.
Thanks!
> I have taken the liberty to optimize the existing int64 function by removing
> spurious tests.
Which are?
> I have not created uint64 specific inlined overfl
Bonjour Michaël,
So I'll set out to write and use "pg_strtou?int64", i.e. 2 functions, and
then possibly generalize to lower sizes, 32, 16, depending on what is
actually needed.
I am interested in this patch, and the next commit fest is close by.
Are you working on an updated version? If not
Bonjour Michaël,
The error returning stuff is simple enough, but I'm unclear about what to do
with pg_uint64, which has a totally different signature. Should it be
aligned?
I am not sure what you mean with aligned here.
I meant same signature.
If you mean consistent, getting into a state w
On Mon, Aug 26, 2019 at 11:05:55AM +0200, Fabien COELHO wrote:
> I have started to do something, and I can spend some time on that this week,
> but I'm pretty unclear about what exactly should be done.
Thanks.
> The error returning stuff is simple enough, but I'm unclear about what to do
> with p
Bonjour Michaël,
So I'll set out to write and use "pg_strtou?int64", i.e. 2 functions, and
then possibly generalize to lower sizes, 32, 16, depending on what is
actually needed.
I am interested in this patch, and the next commit fest is close by.
Are you working on an updated version? If not
Hi Fabien,
On Thu, Aug 01, 2019 at 04:48:35PM +0200, Fabien COELHO wrote:
> Ok, so there is an agreement on reworking the unsigned function. I missed
> this bit.
>
> So I'll set out to write and use "pg_strtou?int64", i.e. 2 functions, and
> then possibly generalize to lower sizes, 32, 16, depend
extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
called 3 times, always with base == 10. We have a similar name but a totally
different interface, so basically it would have to be replaced
by something like the first interface.
My understanding on this one was to nuke
On Thu, Aug 01, 2019 at 11:34:34AM +0200, Fabien COELHO wrote:
> However there is a contrary objective to have a unified interface,
> but there also exists a:
>
> extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
>
> called 3 times, always with base == 10. We have a simila
Michaël-san,
I have looked quickly at it, but I'm not sure that there is an agreement
about what should be done precisely, so the feedback is not clearly
actionable.
Per the latest trends, it seems that the input of Andres was kind of
the most interesting pieces.
Yes, definitely. I understo
On Thu, Aug 01, 2019 at 09:00:41AM +0200, Fabien COELHO wrote:
> I have looked quickly at it, but I'm not sure that there is an agreement
> about what should be done precisely, so the feedback is not clearly
> actionable.
Per the latest trends, it seems that the input of Andres was kind of
the mos
Bonjour Michaël,
Yep, I will try for this week.
Please note that for now I have marked the patch as returned with
feedback as the CF is ending.
Ok.
I have looked quickly at it, but I'm not sure that there is an agreement
about what should be done precisely, so the feedback is not clearly
On Mon, Jul 29, 2019 at 07:04:09AM +0200, Fabien COELHO wrote:
> Bonjour Michaël,
> Yep, I will try for this week.
Please note that for now I have marked the patch as returned with
feedback as the CF is ending.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2019-07-29 10:48:41 +0900, Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 09:16:22PM -0700, Andres Freund wrote:
> >> - One set of functions for the backend, called pg_stro[u]intXX_backend
> >> or pg_backend_stro[u]intXX which can take as extra argument error_ok,
> >> calling the portions
Bonjour Michaël,
Fabien, are you planning to send an updated patch? This stuff has
value.
Yep, I will try for this week.
--
Fabien.
On Thu, Jul 18, 2019 at 09:16:22PM -0700, Andres Freund wrote:
> On 2019-07-19 12:21:27 +0900, Michael Paquier wrote:
> Why not common? It's not a platform dependent bit. Could even be put
> into the already existing string.c.
That would be fine to me, it is not like this file is bloated now.
>>
Hi,
On 2019-07-19 12:21:27 +0900, Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 07:57:41AM +, Fabien COELHO wrote:
> > I'm unhappy with the function names though, feel free to improve.
>
> I would have something rather close to what you are suggesting, still
> not exactly that because we j
On Thu, Jul 18, 2019 at 07:57:41AM +, Fabien COELHO wrote:
> I'm unhappy with the function names though, feel free to improve.
I would have something rather close to what you are suggesting, still
not exactly that because we just don't care about the error strings
generated for the frontend.
Hello Andres,
If a function reports an error to log, it should keep on doing it, otherwise
there would be a regression.
Err, huh. Especially if we change the signature, I fail to see how it's
a regression if we change the behaviour.
ISTM that we do not understand one another, because I'm o
Hi,
On 2019-07-18 09:28:28 +0900, Michael Paquier wrote:
> On Wed, Jul 17, 2019 at 11:14:28AM -0700, Andres Freund wrote:
> > That'd be considerably slower, so I'm *strongly* against that. These
> > conversion routines are *really* hot in a number of workloads,
> > e.g. bulk-loading with COPY. Ch
On Wed, Jul 17, 2019 at 11:14:28AM -0700, Andres Freund wrote:
> That'd be considerably slower, so I'm *strongly* against that. These
> conversion routines are *really* hot in a number of workloads,
> e.g. bulk-loading with COPY. Check e.g.
> https://www.postgresql.org/message-id/20171208214437.qg
Hi,
On 2019-07-17 22:59:01 +, Fabien COELHO wrote:
> > > > with an interface inconsistent with its int32/int16 relatives now only
> > > > in the backend.
> > >
> > > We can, but I'm not at ease with changing the error handling approach.
> >
> > Why?
>
> If a function reports an error to log
- The str->integer conversion routines, which actually have very
similar characteristics to the strtol families as they remove trailing
whitespaces first, check for a sign, etc, except that they work only
on base 10. And here we get into a state where pg_scanint8 should be
actually called pg_
Hi,
On 2019-07-17 17:29:58 +0900, Michael Paquier wrote:
> Actually, one thing which may be a problem is that we lack currently
> the equivalents of pg_mul_s16_overflow and such for unsigned
> integers.
It's much simpler to implement them for unsigned than for signed,
because unsigned overflow is
Hi,
On 2019-07-17 07:55:39 +, Fabien COELHO wrote:
> > - The str->integer conversion routines, which actually have very
> > similar characteristics to the strtol families as they remove trailing
> > whitespaces first, check for a sign, etc, except that they work only
> > on base 10. And here
Hi,
On 2019-07-17 12:04:32 +0900, Michael Paquier wrote:
> On Tue, Jul 16, 2019 at 01:18:38PM -0700, Andres Freund wrote:
> > I'd probably also just use the implementation we have for signed
> > integers (minus the relevant negation and overflow checks, obviously) -
> > it's a lot faster, and I th
Hi,
On 2019-07-17 12:18:19 +0900, Michael Paquier wrote:
> On Tue, Jul 16, 2019 at 01:04:38PM -0700, Andres Freund wrote:
> > There is the issue that there already is pg_strtoint16 and
> > pg_strtoint32, which do not have the option to not raise an error. I'd
> > probably name the non-error throw
On 2019-Jul-16, Thomas Munro wrote:
> On Mon, Jul 15, 2019 at 5:08 PM Fabien COELHO wrote:
> > The compromise I can offer is to change the name of the first one, say to
> > "pg_scanint8" to reflect its former backend name. Attached a v4 which does
> > a renaming so as to avoid the name similarity
On Wed, Jul 17, 2019 at 07:55:39AM +, Fabien COELHO wrote:
>> numutils.c also has pg_strtoint16 and pg_strtoint32, so the locations
>> become rather inconsistent with inconsistent APIs for the manipulation
>> of int2 and int4 fields, and scanint8 is just a derivative of the same
>> logic. We h
Bonjour Michaël,
FWIW, I was looking forward to putting my hands on this patch and try
to get it merged so as we can get rid of those duplications. Here are
some comments.
+#ifdef FRONTEND
+ fprintf(stderr,
+ "invalid input syntax for type %s: \"%s\"\n",
"bigint", str);
+#
On Tue, Jul 16, 2019 at 01:04:38PM -0700, Andres Freund wrote:
> There is the issue that there already is pg_strtoint16 and
> pg_strtoint32, which do not have the option to not raise an error. I'd
> probably name the non-error throwing ones something like pg_strtointNN_e
> (for extended, or error
On Tue, Jul 16, 2019 at 01:18:38PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-07-16 16:11:44 +0900, Michael Paquier wrote:
> Yea, consistent naming seems like a strong requirement
> here. Additionally I think we should just provide a consistent set
> rather than what's needed just now. That'll
Hi,
On 2019-07-16 16:11:44 +0900, Michael Paquier wrote:
> numutils.c also has pg_strtoint16 and pg_strtoint32, so the locations
> become rather inconsistent with inconsistent APIs for the manipulation
> of int2 and int4 fields, and scanint8 is just a derivative of the same
> logic. We have two
Hi,
On 2019-07-15 07:08:42 +0200, Fabien COELHO wrote:
> I do not think that changing the error handling capability is appropriate,
> it is really a feature of the function. The function could try to use an
> internal pg_strtoint64 which would look like the other unsigned version, but
> then it wo
Robert Haas writes:
> On Jul 16, 2019, at 3:30 AM, Fabien COELHO wrote:
>>> Cool. I'm not exactly sure when we should include 'pg_' in identifier
>>> names.
>> I added the pg_ prefix as a poor man's namespace because the function can be
>> used by external tools (eg contribs), so as to avoid p
On Jul 16, 2019, at 3:30 AM, Fabien COELHO wrote:
>> Cool. I'm not exactly sure when we should include 'pg_' in identifier
>> names. It seems to be used for functions/macros that wrap or replace
>> something else with a similar name, like pg_pwrite(),
>> pg_attribute_noreturn(), ... In this ca
Hello Thomas,
On Mon, Jul 15, 2019 at 5:08 PM Fabien COELHO wrote:
The compromise I can offer is to change the name of the first one, say to
"pg_scanint8" to reflect its former backend name. Attached a v4 which does
a renaming so as to avoid the name similarity but signature difference. I
al
On Tue, Jul 16, 2019 at 7:11 PM Michael Paquier wrote:
> Thomas, are you planning to look at this patch as committer? I had it
> in my agenda, and was planning to look at it sooner than later. Now
> if you are on it, I won't step on your toes.
Hi Michael, please go ahead, it's all yours.
--
T
On Tue, Jul 16, 2019 at 11:16:31AM +1200, Thomas Munro wrote:
> Cool. I'm not exactly sure when we should include 'pg_' in identifier
> names. It seems to be used for functions/macros that wrap or replace
> something else with a similar name, like pg_pwrite(),
> pg_attribute_noreturn(), ... In t
On Mon, Jul 15, 2019 at 5:08 PM Fabien COELHO wrote:
> The compromise I can offer is to change the name of the first one, say to
> "pg_scanint8" to reflect its former backend name. Attached a v4 which does
> a renaming so as to avoid the name similarity but signature difference. I
> also made both
Hello Thomas,
+extern bool pg_strtoint64(const char *str, bool errorOK, int64 *result);
+extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
One of these things is not like the other.
Indeed.
I agree that it is unfortunate, and it was bothering me a little as well.
Let'
On Sun, Jul 14, 2019 at 3:22 AM Fabien COELHO wrote:
> Here is the updated patch on which I checked "make check-world".
Thanks! So, we're moving pg_strtouint64() to a place where frontend
code can use it, and getting rid of some duplication. I like it. I
wanted this once before myself[1].
+ex
Hello Thomas,
pg_stat_statements.c:1024:11: error: implicit declaration of function
'pg_strtouint64' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
rows = pg_strtouint64(completionTag + 5, NULL, 10);
^
Apparently it needs to incl
On Mon, Jul 8, 2019 at 3:22 PM Thomas Munro wrote:
> Here's some semi-automated feedback, noted while going through
> failures on cfbot.cputube.org. You have a stray editor file
> src/backend/parser/parse_node.c.~1~. Something is failing to compile
> while doing the temp-install in make check-wo
On Fri, May 24, 2019 at 3:23 AM Fabien COELHO wrote:
> >> 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
> >> back
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.
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 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
86 matches
Mail list logo
