Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Attached patch allows to setup storage parameter for space
reservation.
What is the point of this? We don't need it for 8.3-8.4, we aren't
going to back-patch such a thing into 8.2 or before (certainly not
before, since reloptions
--On Sonntag, November 09, 2008 18:25:50 -0600 Decibel!
[EMAIL PROTECTED] wrote:
On Nov 7, 2008, at 9:53 AM, Tom Lane wrote:
FWIW, I don't see this patch as being terribly useful in the real world
until it can take place in the background, without locking stuff for a
huge amount of time.
Michael Meskes [EMAIL PROTECTED] writes:
is there a reason why we sometimes use ICONST and SCONST directly in a rule in
gram.y yet in other rules use Iconst and Sconst which in turn resolve to
ICONST
and SCONST? Some rules even use ICONST and Sconst, so there does not be any
consistency.
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I have a question about the result contract of pg_do_encoding_conversion().
It's poorly designed :-(
As near as I can tell, all uses of the function either pass a
null-terminated string or special-case the result == src case in such a
way that it
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
What is the point of this? We don't need it for 8.3-8.4, we aren't
going to back-patch such a thing into 8.2 or before (certainly not
before, since reloptions didn't exist before 8.2), and I would hope we
put in a more general
2008/11/10 David Rowley [EMAIL PROTECTED]:
Hitoshi Harada wrote:
I found how to do it, though it's only on the case you gave. Thinking
about the planner optimization of the Window nodes (and its attached
Sort nodes), we must consider the execution order of more than one
node. In the test case
Hi, Simon
Thank you for the review.
On Fri, Nov 7, 2008 at 5:49 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2008-11-05 at 23:17 +0900, Fujii Masao wrote:
Authentication
---
As pointed out at another thread, for authentication, I defined the database
only for
Tom Lane wrote:
Decibel! [EMAIL PROTECTED] writes:
I think that's pretty seriously un-desirable. It's not at all
uncommon for databases to stick around for a very long time and then
jump ahead many versions. I don't think we want to tell people they
can't do that.
Of course they
2008/11/9 David Rowley [EMAIL PROTECTED]:
I've done a little testing with NTILE(). I think a check should be added to
the ntile() function in wfunc.c.
david=# select name,salary,ntile(0) over (order by salary) as n from
employees;
ERROR: floating-point exception
DETAIL: An invalid
2008/11/9 David Rowley [EMAIL PROTECTED]:
I'm having a little trouble understanding the standard for NTH_VALUE(). I
would have assumed that NTH_VALUE(name,1) would return the first name in the
window. The current patch is using 0 for the first.
Hmmm, good point... I haven't thought about it
Brendan Jurd wrote:
On Sat, Nov 8, 2008 at 2:19 AM, Ron Mayer [EMAIL PROTECTED] wrote:
Hmmm... Certainly what I had in datatype.sgml was wrong, but I'm
now thinking 5.5.4.2.1 and 5.5.4.2.2 would be the most clear?
Sorry, I don't understand what you mean by 5.5.4.2.1. In the spec
Ah! That
On Mon, Nov 10, 2008 at 08:12:49AM -0500, Tom Lane wrote:
Which direction are you hoping to go --- remove Iconst/Sconst, or use
them everywhere?
For ecpg I don't care, I have to make some changes during translation anyway.
Right now my script just sets both to ecpg_iconst. There is a small
The attached version now is able to generate an ecpg parser without a single
change in gram.y. Also included is a perl version of the script created by a2p
and fixed by me. Unfortunately a2p did not generate working code, so I guess
eventually we have to only work with the perl version. I guess a
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add other
topic which should be finished for 8.4.
Convert on read has been selected as a good way, because it is not invasive and
does not limit fresh
Greg Stark wrote:
I think double buffering solves the torn page problem but not the lack
of wal logging. Alvarro solved the wal logging by deferring the wal
logs. But I'm not sure how confident we are that it's logging enough.
Right now, it's WAL-logging HeapTupleHeader hint bits
Robert Haas napsal(a):
Let's suppose, for example, that in 8.5 we decide to change some type
that is presently 16 bits to 32 bits, or 8 bits to 16 bits, etc. This
will make some tuples bigger, and potentially much bigger, but since
it presumably won't be a commonly used data-type, most tuples
Hi, Pavan,
On Thu, Nov 6, 2008 at 9:35 PM, Pavan Deolasee [EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 2:12 PM, Fujii Masao [EMAIL PROTECTED] wrote:
If the database whose timeline is the same as the primary's
exists in the standby, 2)3) getting new online-backup is not
necessary. For
Dirk Riehle wrote:
I have a short CVS question please: How do I go from a particular file
revision like
pgsql/cvs/pgsql/src/backend/parser/parse_relation.c.1.3
to the complete commit?
Also try cvs2cl, which might help you:
common_args=--revisions --no-indent --no-wrap
Hi,
is there a reason why we sometimes use ICONST and SCONST directly in a rule in
gram.y yet in other rules use Iconst and Sconst which in turn resolve to ICONST
and SCONST? Some rules even use ICONST and Sconst, so there does not be any
consistency. If this has no reason I'd like to make all
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Otherwise, looks good.
OK. Should we backpatch this? Arguably it's a build bug.
Yeah, probably.
(Also it would be good if someone were to whisper in the ears of the
Fedora people that removing ExtUtils::Embed entirely from their
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches;
Thank you for reviewing.
Jeff Davis [EMAIL PROTECTED] wrote:
Another question: what is explain.log_analyze supposed to do? Changing
it doesn't seem to have an effect; it always prints out the actual time.
That's because explain.log_analyze requires executor instruments,
and it's not free. I
I updated the patch set of SE-PostgreSQL (revision 1206)
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1206.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1206.patch
[3/6]
On Tue, Nov 11, 2008 at 2:36 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
I updated my web site[1] with the latest version of this patch.
I'm just testing this latest version out now.
I get the expected result from 'P0001', but oddly enough if I specify
only the year and month, it pukes:
postgres=#
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:
We should probably standardize on the perl version, ugly or not,
because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as
long
as no one has to look at it ;-)
I have a question about the result contract of pg_do_encoding_conversion().
It can receive non null-terminated string because its arguments are
a char array and a byte length.
And it only returns a string, so the string should be null-terminated.
However, if conversions are not required, the
On Mon, 2008-11-10 at 09:14 -0500, Matthew T. O'Connor wrote:
Tom Lane wrote:
Decibel! [EMAIL PROTECTED] writes:
I think that's pretty seriously un-desirable. It's not at all
uncommon for databases to stick around for a very long time and then
jump ahead many versions. I don't
On Wed, Nov 05, 2008 at 04:06:11PM -0800, Bryce Cutt wrote:
The error is causes by me Asserting against the wrong variable. I
never noticed this as I apparently did not have assertions turned on
on my development machine. That is fixed now and with the new patch
version I have attached all
[EMAIL PROTECTED] (Jonah H. Harris) writes:
On Sun, Nov 9, 2008 at 7:41 PM, Decibel! [EMAIL PROTECTED] wrote:
I think you're barking up the wrong tree here; the community can't really do
hacking for hire. If you want to pay for something to be implemented (which
is great!), you'll need to talk
Decibel! napsal(a):
Unless I'm mistaken, there are only two cases we care about for
additional space: per-page and per-tuple.
Yes. And maybe special space indexes could be extended, but it is covered in
per-page setting.
Those requirements could also
vary for different types of pg_class
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Stark wrote:
I'm beginning to think just excluding the hint bits would be simpler and
safer. If we're double buffering then it might be possible to do that
pretty cheaply. Copy the whole buffer with memcpy then loop through the
line pointers
Ron Mayer wrote:
Ah! That 5.5.4.2.1 comes from apparently an old Oct 2000
draft version of the spec titled ISO/FDIS 8601. (For now you can
see it here: http://0ape.com/postgres_interval_patches/ISO-FDIS-8601.pdf )
I'll fix all the links to point to the 2004 spec.
I updated my web site[1]
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Seems to me there's one there already.
You're thinking of initdb maybe? I'm talking about createdb.
Oh, okay. But how often is someone going to be changing locales during
createdb? I think the most common case
Michael Meskes [EMAIL PROTECTED] writes:
On Mon, Nov 10, 2008 at 08:12:49AM -0500, Tom Lane wrote:
Which direction are you hoping to go --- remove Iconst/Sconst, or use
them everywhere?
For ecpg I don't care, I have to make some changes during translation anyway.
Right now my script just
On Sun, Nov 09, 2008 at 11:28:50PM -0500, Robert Haas wrote:
Well, if that's what it is, I think it's a fairly poor design
decision. When I upgrade Oracle, SQL Server, or MySQL, I don't need
to plan the amount of free space in my blocks a year or more before an
upgrade. In fact, I don't
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: src/bin/scripts/createdb.c
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks fine.
On Thu, Nov 6, 2008 at 8:08 PM, Benedek László
[EMAIL PROTECTED] wrote:
Hi,
Thanks for your review.
I created an updated patch according to your notices.
1 - Patch does not apply cleanly on latest git repository, although
there is no hunk failed but there are some hunk succeeded messages.
Michael Meskes [EMAIL PROTECTED] writes:
The attached version now is able to generate an ecpg parser without a single
change in gram.y.
Sweet.
Also included is a perl version of the script created by a2p
and fixed by me. Unfortunately a2p did not generate working code, so I guess
eventually
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
What about the MakeMaker dependency?
The call to ldopts will fail if MakeMaker is not present, so this will
cover it. It's very unlikely to be absent - it's required to build
almost every Perl
On Tue, Nov 11, 2008 at 5:51 AM, R Mayer
[EMAIL PROTECTED] wrote:
Applied and pushed to the website http://0ape.com/postgres_interval_patches/
This latest version works as expected and I don't detect any other
issues with the code or documentation ... seems I've run out of things
to gripe
David E. Wheeler wrote:
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:
We should probably standardize on the perl version, ugly or not, because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as long
as no one
Andrew Dunstan [EMAIL PROTECTED] writes:
I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.
There is no guarantee that the script won't have to be looked
-Original Message-
On Sun, Nov 2, 2008 at 10:49 PM, Jonah H. Harris
[EMAIL PROTECTED] wrote:
It's effective as-is for a preliminary patch. The GUC code is the
least of my worries.
Can you provide some figures on the performance impact of the bloom
filter?
I have tested the
Brendan Jurd [EMAIL PROTECTED] writes:
I'm ready to sign off on this patch now and move on to the final
cleanup patch. I'll update the commitfest to show this one as ready
for committer.
OK, I'll pick this one up now.
regards, tom lane
--
Sent via pgsql-hackers
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.
There is no guarantee that the
Brendan Jurd wrote:
On Tue, Nov 11, 2008 at 2:36 AM, Ron Mayer
I get the expected result from 'P0001', but oddly enough if I specify
only the year and month, it pukes:
postgres=# select interval 'P0001-01';
Indeed. Thanks again.
I've fixed this and added regression tests to check the
Chris Browne wrote:
[EMAIL PROTECTED] (Jonah H. Harris) writes:
On Sun, Nov 9, 2008 at 7:41 PM, Decibel! [EMAIL PROTECTED] wrote:
I think you're barking up the wrong tree here; the community can't really do
hacking for hire. If you want to pay for something to be implemented (which
is great!),
On Sat, Nov 1, 2008 at 3:42 PM, Ron Mayer [EMAIL PROTECTED] wrote:
# Patch 3: cleanup.patch
Fix rounding inconsistencies and refactor interval input/output code
Compile, testing and regression tests all checked out.
I've picked up on a few code style issues, fixes attached.
If I'm reading
On Mon, 2008-11-10 at 21:13 +0100, Josh Berkus wrote:
Chris Browne wrote:
No, but that's where the right people would see it.
Realistically, this means most likely contracting with 2nd Quadrant,
Command Prompt or Peter Eisentraut.
I would note that the individual has been hitting
Josh,
I would note that the individual has been hitting *everyone* directly
and via list. So either he is quite serious, doesn't understand
etiquette or is a spammer.
I think there is a language barrier at work.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Hitoshi Harada wrote:
The spec says: The ROW_NUMBER function computes the sequential row
number,
starting with 1 (one) for the first row, of the row within its window
partition according to the window ordering of the window.
I'm just not sure if we should block this or not.
Does
On Mon, 2008-11-10 at 21:21 +0100, Josh Berkus wrote:
Josh,
I would note that the individual has been hitting *everyone* directly
and via list. So either he is quite serious, doesn't understand
etiquette or is a spammer.
I think there is a language barrier at work.
Oh certainly a
On Nov 9, 2008, at 11:09 PM, Joshua D. Drake wrote:
I think it's time for people to stop asking for the moon and realize
that if we don't constrain this feature pretty darn tightly, we will
have *nothing at all* for 8.4. Again.
Gotta go with Tom on this one. The idea that we would somehow
On Mon, Nov 10, 2008 at 2:42 PM, Lawrence, Ramon [EMAIL PROTECTED] wrote:
I have tested the Bloom filter patch. It compiles cleanly against HEAD.
Thank you for testing this!
As indicated, the performance improvements for hash join are good,
especially when the build table is filtered with a
Josh Berkus Wrote:
I would suggest submitting it to pgsql-jobs.
Except that it's not a job offer - it's more of a solicitation for
implementation of something, so I'm not sure that's the right place
either.
No, but that's where the right people would see it.
Realistically, this
Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
Also included is a perl version of the script created by a2p
and fixed by me. Unfortunately a2p did not generate working code, so I guess
eventually we have to only work with the perl version. I guess a perl hacker
can beautify the
On Mon, 2008-11-10 at 20:48 +, David Rowley wrote:
Josh Berkus Wrote:
I would suggest submitting it to pgsql-jobs.
Apart from the post during a commitfest does this not fit in with the
details given here:
http://wiki.postgresql.org/wiki/How_to_sponsor_a_feature
Or is sponsoring
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to un-
uglify this.
My Perl is excellent, but my awk is remedial. What part does awk play?
Best,
David
--
David E. Wheeler wrote:
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to
un-uglify this.
My Perl is excellent, but my awk is remedial. What part does awk
Brendan Jurd [EMAIL PROTECTED] writes:
I *was* going to question the inconsistent use of a space between the
pointer qualifier and the argument name, for example:
...
But then I noticed that there's a lot of this going on in datetime.c,
some of it appears to predate your patches.
Any
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Stark wrote:
I'm beginning to think just excluding the hint bits would be simpler and
safer. If we're double buffering then it might be possible to do that
pretty cheaply. Copy the whole buffer with memcpy
On Sun, 2008-11-09 at 20:18 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Will think some more and report back.
If you want to do some more development, here's the portion of the
patch as yet unapplied --- will save you extracting it for yourself.
Thanks.
More thought
Gregory Stark wrote:
I think you could checksum the block including the hint bits then go back and
remove them from the checksum.
I'm not sure what you're proposing here. It sounds to me like you are
saying that we can read the page, make it available to other users, and
then check the CRC.
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
I think you could checksum the block including the hint bits then go back and
remove them from the checksum.
I'm not sure what you're proposing here. It sounds to me like you are
saying that we can read the page, make it
Andrew Dunstan wrote:
David E. Wheeler wrote:
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to
un-uglify this.
My Perl is excellent, but my
Zdenek Kotala wrote:
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add other
topic which should be finished for 8.4.
Convert on read has been selected as a good way, because it is not invasive
David Rowley escribió:
Or is sponsoring a feature paying money to people that already plan to
implement something?
Nobody on their mind would plan to implement the features being proposed
here ... I didn't look very far but it seems mainly nonsense.
--
Alvaro Herrera
Joshua D. Drake escribió:
On Mon, 2008-11-10 at 20:48 +, David Rowley wrote:
Josh Berkus Wrote:
I would suggest submitting it to pgsql-jobs.
Apart from the post during a commitfest does this not fit in with the
details given here:
On Mon, 2008-11-10 at 18:22 +0900, Fujii Masao wrote:
Yeah, I also add walsender as new auxiliary process at first. But,
during coding,
I made out that this is more complicated for code and user.
First problem : Which process accepts the connection from standby?
IMO, *postmaster* should
Simon Riggs [EMAIL PROTECTED] writes:
More thought tells me that we should have a
LockRelationForCatalogUpdate() that uses nearly the same design pattern
as LockRelationForExtension(). There is no lockmode since we always take
the lock in exclusive mode.
This works only for updaters that
Bruce Momjian [EMAIL PROTECTED] writes:
1) Data does not fit on the new page. It will be solve by pre-upgrade check
which reserve space on each page, before upgrade.
Rather than specifying free space as an amount, I was thinking of having
a boolean like 'ready_for_upgrade' and the system
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
1) Data does not fit on the new page. It will be solve by pre-upgrade
check
which reserve space on each page, before upgrade.
Rather than specifying free space as an amount, I was thinking of having
a boolean like
Tom Lane [EMAIL PROTECTED] wrote:
Do you have a proposal for a different API, or do you just want to
improve the comment for the function? Bear in mind that a lot of the
callers do know the string length, and so we shouldn't impose an
unnecessary strlen() operation on those cases.
We
R Mayer [EMAIL PROTECTED] writes:
Applied and pushed to the website http://0ape.com/postgres_interval_patches/
I ran into an interesting failure case:
regression=# select interval 'P-1Y-2M3DT-4H-5M-6';
interval
---
P-1Y-2M3DT-10H-5M
(1 row)
This isn't the result I'd
-Original Message-
From: Jonah H. Harris [mailto:[EMAIL PROTECTED]
I have a new patch which does not create a bloom filter unless it sees
that the hash join is going to batch. I'll send it along later
tonight.
Currently it's additional space not accounted for by work_mem.
I got a problem when reviewing patch Automatically update view, the code can
be built and executed successfully, but when i tried the eaxmple below, it
seemed that the patch didn't work
create view v_name_account
as
select customer.name,
customer.age,
customer.city,
R Mayer [EMAIL PROTECTED] writes:
Applied and pushed to the website http://0ape.com/postgres_interval_patches/
Applied with nontrivial revisions --- I fear I probably broke your third
patch again :-(. There were still a number of parsing bugs, and I also
didn't like the lack of error checking
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Do you have a proposal for a different API, or do you just want to
improve the comment for the function? Bear in mind that a lot of the
callers do know the string length, and so we shouldn't impose an
unnecessary
I have a comment about reloptions of autovacuum parameters:
I'd like to have an easier way to extract individual parameters.
Alvaro Herrera [EMAIL PROTECTED] wrote:
Euler Taveira de Oliveira wrote:
What did I already do? I refactored reloptions.c to support multiple
options. I tried to
Here is another example for testing Automatic update view, seems that check
option doesn't work, i am not sure any other things i need to do, or it is a
bug for the patch, anyone give me a help?
Thanks
postgres=# create view old_customer as
postgres-# select name,
postgres-# age,
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
OK, I have spent some time generating and filtering typdefs via objdump
on various platforms. I filtered them and Bruce's list to eliminate
items not actually found in the sources thus:
Did this go
Hi,
On Thu, Nov 6, 2008 at 3:59 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Again, I would expect this to be integrated with server. I would expect
code to live in src/postmaster/walreceiver.c, with main logic in a file
alongside xlog.c, perhaps xreceive.c. We would start WALReceiver when we
On Mon, Nov 10, 2008 at 10:40 PM, Unicron [EMAIL PROTECTED] wrote:
Here is another example for testing Automatic update view, seems that
check option doesn't work, i am not sure any other things i need to do, or
it is a bug for the patch, anyone give me a help?
actually that is intentional,
On Mon, Nov 10, 2008 at 8:27 PM, Unicron [EMAIL PROTECTED] wrote:
I got a problem when reviewing patch Automatically update view, the code
can be built and executed successfully, but when i tried the eaxmple below,
it seemed that the patch didn't work
AFAIR, this patch only supports SQL92 so
Hi,
Trying to review some patches on windows... mingw: 5.1.4; msys:
1.0.10; gcc 3.4.5
This is not current head but this morning snapshot tarball... but i
saw this same error with yesterday tarball...
I get this failure on regression tests:
expected output:
SELECT '10e-400'::float8;
! ERROR:
On Mon, Nov 3, 2008 at 8:41 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Hello, Saito-san:
Hiroshi Saito [EMAIL PROTECTED] wrote:
next patch is this.
I'm reviewing your patch and cleanup some parts:
i'm confused, original patch has this signature:
+ conv_strftime(char *src, size_t len,
88 matches
Mail list logo