Tom Lane wrote:
Josh Berkus writes:
On 3/29/10 7:46 AM, Joachim Wieland wrote:
I actually assume that whenever people are interested
in a very fast dump, it is because they are doing some maintenance
task (like migrating to a different server) that involves pg_dump. In
these cases, they would
Alvaro Herrera wrote:
Josh Berkus escribió:
And snaphsots have more compile dependancies than releases do.
As far as I know, a snapshot is identical to a "release" in that regard.
If they are not, that's a bug and we can fix it before weekend.
yeah - snapshots do have the same compile time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 30, 2010 at 01:33:59AM +0530, Anindya Jyoti Roy wrote:
> I have some idea of implementing am image database system, which will let
> you search against the image and fingerprint:
As others already pointed out, this seems a huge task for a
Hi, I have some questions about 9.0 release note.
I'd like to work for some of them if required. Comments welcome.
* Allow per-tablespace sequential and random page cost variables
(seq_page_cost/(random_page_cost)) via ALTER TABLESPACE ... SET/RESET
^^
Are those
On Wed, Mar 3, 2010 at 9:41 PM, Fujii Masao wrote:
> On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao wrote:
>> If standby_mode is enabled, and neither primary_conninfo nor restore_command
>> are set, the standby would get stuck. How about forbidding (i.e., causing a
>> FATAL message) this wrong sett
On Tue, 2010-03-30 at 01:33 +0530, Anindya Jyoti Roy wrote:
> I have some idea of implementing am image database system, which will
> let you search against the image and fingerprint:
>
> The idea crudely is the following:
>
> I want to implement a image database system: This will have the
> fo
Josh Berkus escribió:
> And snaphsots have more compile dependancies than releases do.
As far as I know, a snapshot is identical to a "release" in that regard.
If they are not, that's a bug and we can fix it before weekend.
--
Alvaro Herrerahttp://www.CommandProm
On Mon, 2010-03-29 at 19:08 -0400, Robert Haas wrote:
> To be really useful, this would probably need
> some kind of index support, maybe based on GIN.
Yes.
> You're not going to
> get that done by August even if you start now and don't sleep.
The extensibility mechanism is designed so that an
Maybe this can be helpful:
http://sourceforge.net/search/?type_of_search=soft&words=fingerprint
http://sourceforge.net/search/?type_of_search=soft&words=image+recogniti
on
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Beh
Last i heard from Dave on that topic is that there's no chance of that
happening that quickly. He's on a plane now but I'm sure he'll confirm that
when he lands.
/Magnus
On Mar 29, 2010 6:14 PM, "Peter Eisentraut" wrote:
On sön, 2010-03-28 at 19:22 -0400, Robert Haas wrote:
> On Sun, Mar 28, 20
> The idea crudely is the following:
>
> I want to implement a image database system: This will have the
> following quality:
This seems fine, but I believe it's been done before. You might want to
search for existing projects, and make an improvement on an existing
project rather than starting
On Mon, Mar 29, 2010 at 4:03 PM, Anindya Jyoti Roy wrote:
> I want to implement a image database system: This will have the following
> quality:
> 1> will store image along with the other attributes
> 2> the database search engine will be able to search for image also
> 3> it will list the matchin
On sön, 2010-03-28 at 19:22 -0400, Robert Haas wrote:
> On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus wrote:
> > We've got two locations and some individuals signed up for a test-fest
> > this weekend. Would it be possible to do an alpha release this week?
> > It would really help to be testing la
On Mon, Mar 29, 2010 at 3:57 PM, Robert Haas wrote:
> On Mon, Mar 29, 2010 at 3:55 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> You're not addressing the original point. I have
On Mon, Mar 29, 2010 at 4:40 PM, Stefan Kaltenbrunner
wrote:
> yeah but you also need people changing the website - and probably more
> important given that josh wants windows as well help from dave for doing a
> new windows installer :)
True... well, I can't help with those bits. :-)
...Rober
Robert Haas wrote:
It's completely possible that you could want to clone a server for dev
and have more CPU and I/O bandwidth available than can be efficiently
used by a non-parallel pg_dump. But certainly what Joachim is talking
about will be a good start. I think there is merit to the
sync
Robert Haas wrote:
On Mon, Mar 29, 2010 at 2:52 PM, Josh Berkus wrote:
or just use a specific recent snapshot and let people test that just in
case it is not feasible doing a new alpha on short notice.
Doesn't work if we want to test it on windows. And snaphsots have more
compile dependancies
Alex Hunsaker writes:
> It comes to mind you can probably do this with an plannerhook
> (whatever happened to those hooks to auto create/recommend indexes?)
Uh, we made some hooks to let someone build an *external* module that
would do such a thing. Whether anybody got anywhere with it I dunno.
On Mon, Mar 29, 2010 at 4:11 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 3/29/10 7:46 AM, Joachim Wieland wrote:
>>> I actually assume that whenever people are interested
>>> in a very fast dump, it is because they are doing some maintenance
>>> task (like migrating to a different server) tha
On Mon, 2010-03-29 at 13:54 -0600, Alex Hunsaker wrote:
> whatever happened to those hooks to auto create/recommend indexes?
You haven't published them yet??
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Dimitri Fontaine writes:
> Tom Lane writes:
>> If this is going to end up being one fairly small C file implementing
>> a spec that is not a moving target, I'd vote against depending on an
>> external library instead, no matter how spiffy and license-compatible
>> the external library might be.
On Mon, 2010-03-29 at 15:55 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
> >> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> >>> You're not addressing the original point. I have been asked how would
> >>> users know which tables hav
Josh Berkus writes:
> On 3/29/10 7:46 AM, Joachim Wieland wrote:
>> I actually assume that whenever people are interested
>> in a very fast dump, it is because they are doing some maintenance
>> task (like migrating to a different server) that involves pg_dump. In
>> these cases, they would stop t
On Mon, Mar 29, 2010 at 3:55 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
>>> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
You're not addressing the original point. I have been asked how would
users know which tables have bee
Simon Riggs writes:
> On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
>> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
>>> You're not addressing the original point. I have been asked how would
>>> users know which tables have been removed and whether there is a way of
>>> checking tha
On Mon, Mar 29, 2010 at 13:41, Simon Riggs wrote:
>> Uhh... they wont be in the explain output... Seems simple enough.
>
> That is exactly what I replied, though nobody felt that was a great
> answer.
Maybe I missed it, but why exactly do they care? About the only
reason I can think *i* would c
Tom Lane writes:
> If this is going to end up being one fairly small C file implementing
> a spec that is not a moving target, I'd vote against depending on an
> external library instead, no matter how spiffy and license-compatible
> the external library might be.
My understanding is that it's po
On 3/29/10 7:46 AM, Joachim Wieland wrote:
> I actually assume that whenever people are interested
> in a very fast dump, it is because they are doing some maintenance
> task (like migrating to a different server) that involves pg_dump. In
> these cases, they would stop their system anyway.
Actual
On Mon, Mar 29, 2010 at 2:52 PM, Josh Berkus wrote:
>
>> or just use a specific recent snapshot and let people test that just in
>> case it is not feasible doing a new alpha on short notice.
>
> Doesn't work if we want to test it on windows. And snaphsots have more
> compile dependancies than rel
On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> > You're not addressing the original point. I have been asked how would
> > users know which tables have been removed and whether there is a way of
> > checking that.
>
> Uhh... they wont
On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> You're not addressing the original point. I have been asked how would
> users know which tables have been removed and whether there is a way of
> checking that.
Uhh... they wont be in the explain output... Seems simple enough.
--
Sent via pgs
On Tue, 2010-03-23 at 19:43 -0400, Bruce Momjian wrote:
> Is there a reason that recovery.conf uses true/false, while
> postgresql.conf uses on/off?
>
> #recovery_target_inclusive = 'true' # 'true' or 'false'
>
> or are these settings more boolean for some reason?
The code acce
> or just use a specific recent snapshot and let people test that just in
> case it is not feasible doing a new alpha on short notice.
Doesn't work if we want to test it on windows. And snaphsots have more
compile dependancies than releases do.
Also ... this isn't short notice. I requested a n
On Mon, Mar 29, 2010 at 2:23 PM, David E. Wheeler wrote:
> On Mar 29, 2010, at 9:02 AM, Tom Lane wrote:
>
>> If this is going to end up being one fairly small C file implementing
>> a spec that is not a moving target, I'd vote against depending on an
>> external library instead, no matter how spif
On Mar 29, 2010, at 9:02 AM, Tom Lane wrote:
> If this is going to end up being one fairly small C file implementing
> a spec that is not a moving target, I'd vote against depending on an
> external library instead, no matter how spiffy and license-compatible
> the external library might be.
Perh
On Mon, 2010-03-29 at 11:46 -0400, Tom Lane wrote:
> Robert Haas writes:
> > OK, I'll write a patch for that; and a consensus emerges that we
> > should also have enable_joinremoval, then I will add that as well. I
> > think the only argument for NOT having enable_joinremoval is that you
> > can
On Mon, Mar 29, 2010 at 1:16 PM, Stefan Kaltenbrunner
wrote:
> Robert Haas wrote:
>>
>> On Mon, Mar 29, 2010 at 10:46 AM, Joachim Wieland wrote:
>
> [...]
>>>
>>> - Regarding the output of pg_dump I am proposing two solutions. The
>>> first one is to introduce a new archive type "directory" where
On Mon, 2010-03-29 at 09:37 -0400, Robert Haas wrote:
> In many
> cases it's not horribly difficult to work around because you can do
> SELECT * FROM ... instead of your original select list, but there
> might be some cases with multiple levels of views where it isn't that
> easy. I think it woul
On 3/28/10 8:52 PM, Hitoshi Harada wrote:
> There's another choice, called BSON.
>
> http://www.mongodb.org/display/DOCS/BSON
>
> I've not researched it yet deeply, it seems reasonable to be stored in
> databases as it is invented for MongoDB.
I wouldn't take that for granted. The MongoDB project
On Mon, 2010-03-29 at 11:27 -0400, Tom Lane wrote:
> Robert Haas writes:
> > And for the record, I believe I find it rather amusing that you're
> > asking me if I "have the faintest idea how many there would be".
>
> Actually that was directed more at Simon.
I think you should drop the personal
Robert Haas wrote:
On Mon, Mar 29, 2010 at 10:46 AM, Joachim Wieland wrote:
[...]
- Regarding the output of pg_dump I am proposing two solutions. The
first one is to introduce a new archive type "directory" where each
table and each blob is a file in a directory, similar to the
experimental "f
2010/3/29 Tom Lane
> =?ISO-8859-2?Q?=A3ukasz_Dejneka?= writes:
> > What I want to do is to use HStore data type (namely the HStore keys) in
> > TSearch. I don't want use TSVector and the original ts_match_vq function,
> > because I want to be able to control exact values that are passed to the
>
2010/3/29 Tom Lane :
> Pavel Stehule writes:
>> can we add well structured information about function id and lineno to
>> ErrorData?
>
> The idea that I was toying with was to report the function OID and line
> number, which might as well be two separate fields rather than messing
> around with an
Pavel Stehule writes:
> can we add well structured information about function id and lineno to
> ErrorData?
The idea that I was toying with was to report the function OID and line
number, which might as well be two separate fields rather than messing
around with anything "structured".
The OID mi
Tom Lane wrote:
The problem with this line of thought is that it imagines you can look
at worked-out alternative plans. You can't, because the planner doesn't
pursue rejected alternatives that far (and you'd not want to wait long
enough for it to do so...)
Not on any production system, sure
On Mon, Mar 29, 2010 at 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith wrote:
>>> at the top of my list in this area for 9.1 is to track down the rumored
>>> patch that exports information about the rejected plans considered and get
>>> that comit
Hello
this simple patch allow to specify cursor row when some function is
opened in editor.
\e aaa.txt
\a aaa.txt 3 ... move cursor on 3nd line of text
\ef foo
\ef foo 3 ... move cursor on 3nd line of function body
\sf foo ... show function body
\sf+ foo ... show function body - use line numbers
Robert Haas writes:
> On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith wrote:
>> at the top of my list in this area for 9.1 is to track down the rumored
>> patch that exports information about the rejected plans considered and get
>> that comitted. That always seems what I want to look at for answer
On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> The query planner is a great piece of code but it
>> is not so transparently simple that it doesn't need debugging or
>> instrumentation, and "why did the planner do X" has got to be one of
>> our top ten most-frequentl
On Mon, Mar 29, 2010 at 12:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
>> wrote:
>>> My reasoning for "It should be built-in" is:
>>> * It would be nice to have a built-in serialization format that's
>>> available by default.
>>> * It might be
Robert Haas wrote:
The query planner is a great piece of code but it
is not so transparently simple that it doesn't need debugging or
instrumentation, and "why did the planner do X" has got to be one of
our top ten most-frequently asked questions.
Debugging and instrumentation are two slightly
Robert Haas writes:
> On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
> wrote:
>> My reasoning for "It should be built-in" is:
>> * It would be nice to have a built-in serialization format that's
>> available by default.
>> * It might be a little faster because it doesn't have to link to an
>> e
On Mon, Mar 29, 2010 at 11:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> OK, I'll write a patch for that; and a consensus emerges that we
>> should also have enable_joinremoval, then I will add that as well. I
>> think the only argument for NOT having enable_joinremoval is that you
>> can alwa
Robert Haas writes:
> OK, I'll write a patch for that; and a consensus emerges that we
> should also have enable_joinremoval, then I will add that as well. I
> think the only argument for NOT having enable_joinremoval is that you
> can always modify the query to say SELECT * rather than some more
On Mon, Mar 29, 2010 at 11:29 AM, Robert Haas wrote:
> On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova
> wrote:
>> On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera
>> wrote:
>>>
>>> It seems that what's really needed is some debug output to be able to
>>> find out what it did.
>>
>> +1, i was p
On Mon, Mar 29, 2010 at 10:46 AM, Joachim Wieland wrote:
> - There are ideas on how to solve the issue with the consistent
> snapshot but in the end you can always solve it by stopping your
> application(s). I actually assume that whenever people are interested
> in a very fast dump, it is because
On Mon, Mar 29, 2010 at 11:27 AM, Tom Lane wrote:
> Robert Haas writes:
>> And for the record, I believe I find it rather amusing that you're
>> asking me if I "have the faintest idea how many there would be".
>
> Actually that was directed more at Simon.
>
>> I venture to say that after yourself
On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova
wrote:
> On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera
> wrote:
>>
>> It seems that what's really needed is some debug output to be able to
>> find out what it did.
>
> +1, i was preparing an env for testing this but in the while i was
> thinkin
Robert Haas writes:
> And for the record, I believe I find it rather amusing that you're
> asking me if I "have the faintest idea how many there would be".
Actually that was directed more at Simon.
> I venture to say that after yourself I might be the person who knows
> this code best. I know h
On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera
wrote:
>
> It seems that what's really needed is some debug output to be able to
> find out what it did.
>
>
+1, i was preparing an env for testing this but in the while i was
thinking how can i know what happens... counting the tables in the
expla
On Mon, Mar 29, 2010 at 10:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
>>> So I think we need a parameter for join removal also.
>
>> I had this in my original patch but Tom wanted it taken out.
>
> And I still don't want it. We are NOT go
Alvaro Herrera writes:
> It seems that what's really needed is some debug output to be able to
> find out what it did.
Isn't EXPLAIN good enough?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Mon, Mar 29, 2010 at 04:46:48PM +0200, Joachim Wieland wrote:
> People have been talking about a parallel version of pg_dump a few
> times already. I have been working on some proof-of-concept code for
> this feature every now and then and I am planning to contribute this
> for 9.1.
>
> There a
People have been talking about a parallel version of pg_dump a few
times already. I have been working on some proof-of-concept code for
this feature every now and then and I am planning to contribute this
for 9.1.
There are two main issues with a parallel version of pg_dump:
The first one is that
=?ISO-8859-2?Q?=A3ukasz_Dejneka?= writes:
> What I want to do is to use HStore data type (namely the HStore keys) in
> TSearch. I don't want use TSVector and the original ts_match_vq function,
> because I want to be able to control exact values that are passed to the
> search and not use their lex
Tom Lane escribió:
> Robert Haas writes:
> > On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
> >> So I think we need a parameter for join removal also.
>
> > I had this in my original patch but Tom wanted it taken out.
>
> And I still don't want it. We are NOT going in the direction of add
Robert Haas writes:
> On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
>> So I think we need a parameter for join removal also.
> I had this in my original patch but Tom wanted it taken out.
And I still don't want it. We are NOT going in the direction of adding
an enable_ knob for every sin
On Mon, Mar 29, 2010 at 4:21 AM, Joachim Wieland wrote:
> On Mon, Mar 29, 2010 at 12:32 AM, Robert Haas wrote:
>> Per previous discussion, PFA a patch to change the maximum number of
>> keys for a syscache from 4 to 5.
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-02/msg01105.php
>>
>>
On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
>
> We have planner method parameters for many important parts of the
> planner. We don't have any parameter for join removal, AFAIK.
>
> The first question I get asked is "can I see the tables it removed?".
> This has been asked of me 3 times no
Hi,
Michael Meskes írta:
> Hi,
>
> I did some more testing on ecpg and found that allowing variables as cursor
> names seems to produce more problems than I anticipated. But then maybe it's
> just some missing checks to throw out error messages. Anyway, I attach a small
> test program that, from m
Hi,
I have been using PostGreSQL as a part of our healthcare product. As an
important part of releasing a stable product it is important to also
document the known issues found in a PostGRE release. I would be
grateful if someone could forward me to the Known Issues Page(if any).
On these lines h
Robert Haas wrote:
I feel pretty strongly that the data should be stored in the database
in the format in which it will be returned to the user - any
conversion which is necessary should happen on the way in. I am not
100% sure to what extent we should attempt to canonicalize the input
and to
Hi,
I did some more testing on ecpg and found that allowing variables as cursor
names seems to produce more problems than I anticipated. But then maybe it's
just some missing checks to throw out error messages. Anyway, I attach a small
test program that, from my understanding, should work, but dos
Hi,
I've asked this question in novice group and another Postgres forum, but
didn't get any help.
What I want to do is to use HStore data type (namely the HStore keys) in
TSearch. I don't want use TSVector and the original ts_match_vq function,
because I want to be able to control exact values th
>
>
>
> Similarly using the no. of select hits on a table we can check that if
>> maximum no. of times it is on a non-index field we can index on that field
>> to make select faster.
>>
>
> It's impractical to figure out where indexes should go at without
> simulating what the optimizer would then
"Vladimir Barzionov" wrote:
> Same problem was already discussed for example here
> http://dbaspot.com/forums/postgresql/393683-re-general-custom-c-function-palloc-broken.html
>
> Looks like the simplest way for correcting the issue is declaring additional
> macro (something like PGMODULEEXPORT
On mån, 2010-03-29 at 00:04 -0500, David Christensen wrote:
> Enclosed is a patch to add a -C option to initdb to allow you to easily
> append configuration directives to the generated postgresql.conf file for use
> in programmatic generation.
I like this idea, but please use small -c for consis
On sön, 2010-03-28 at 23:24 -0400, Joseph Adams wrote:
> Thus, here's an example of how (in my opinion) character sets and such
> should be handled in the JSON code:
>
> Suppose the client's encoding is UTF-16, and the server's encoding is
> Latin-1. When JSON is stored to the database:
> 1. The
Hello
can we add well structured information about function id and lineno to
ErrorData?
Actually we sending some info - but formated as string and only when
Log_error_verbosity >= PGERROR_VERBOSE.
I hope, so this feature can help to some interactive GUI managers as
pgAdmin, and to psql too.
Reg
Robert Haas wrote:
On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus wrote:
We've got two locations and some individuals signed up for a test-fest
this weekend. Would it be possible to do an alpha release this week?
It would really help to be testing later code than Alpha4.
I'm willing to do the
We have planner method parameters for many important parts of the
planner. We don't have any parameter for join removal, AFAIK.
The first question I get asked is "can I see the tables it removed?".
This has been asked of me 3 times now this year, always first question.
Same issue applies to const
2010/3/29 Marko Tiikkaja :
> On 2010-03-29 11:19 +0200, Pavel Stehule wrote:
>> postgres=# explain select a from a left join b on true;
you have a true.
I forgot SELECT DISTINCT
regards
Pavel
>
> This is effectively a cross join and it would give wrong answers. Try
> SELECT a FROM a LEFT JOIN
On 2010-03-29 11:19 +0200, Pavel Stehule wrote:
> postgres=# explain select a from a left join b on true;
This is effectively a cross join and it would give wrong answers. Try
SELECT a FROM a LEFT JOIN b ON a.a = b.b;
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Mon, Mar 29, 2010 at 12:32 AM, Robert Haas wrote:
> Per previous discussion, PFA a patch to change the maximum number of
> keys for a syscache from 4 to 5.
>
> http://archives.postgresql.org/pgsql-hackers/2010-02/msg01105.php
>
> This is intended for application to 9.1, and is supporting
> infr
Hello
is any reason why join removal doesn't remove useless relation b?
postgres=# \d a
Table "public.a"
Column | Type | Modifiers
+-+---
a | integer |
Indexes:
"a_a_idx" UNIQUE, btree (a)
postgres=# \d b
Table "public.b"
Column | Type | Mo
On Sun, 2010-03-28 at 12:47 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2010-03-26 at 18:59 +, Greg Stark wrote:
> >> It occurs to me we could do the same for CHECK_FOR_INTERRUPTS() by
> >> conditionally having it call a function which calls gettimeofday and
> >> compares with the
Hi,
Joseph Adams writes:
> As for reinventing the wheel, I'm in the process of writing yet
> another JSON implementation simply because I didn't find the other
> ones I looked at palatable.
Even this one (ANSI C, MIT Licenced)?
cJSON -- An ultra-lightweight, portable, single-file, simple-as-c
gaurav gupta wrote:
My idea is to add a functionality of Auto tuning and Auto Indexing/
Reindexing in DB languages.
Ah, the classic request to start with the tuning and index wizards.
Really fun to work on, always lots of interest in it. Here's the
thing: projects in this area attract endl
88 matches
Mail list logo
