.
Agree, I think we should stay at quad tree implemetation.
--
With best regards,
Alexander Korotkov.
, then the first byte of
multibyte must be 0x9c. If the second byte of wchar is in range of
0xf5 to 0xfe, then the first byte of multibyte must be 0x9d.
Should I intergrate these code changes into my patch? Or we would like to
commit them first?
--
With best regards,
Alexander Korotkov.
by thoughts. I
think if he'll verify it in this thread, it should be enough for review of
few lines bugfix.
If we say about bugfix I provided for backpatch, it need more detailed
review. I was a miss that I didn't add it to current commitfest, will add
it to the next one.
--
With best regards,
Alexander
On Tue, Jul 3, 2012 at 10:51 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-07-02 at 23:47 -0700, Jeff Davis wrote:
On Thu, 2012-06-14 at 02:56 +0400, Alexander Korotkov wrote:
Hackers,
attached patch implements quad-tree on ranges. Some performance
results in comparison
On Mon, Jul 2, 2012 at 8:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov aekorot...@gmail.com
wrote:
MULE also looks problematic. The code that you've written isn't
symmetric with the opposite conversion, unlike what you did in all
other
On Tue, Jul 3, 2012 at 12:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 2, 2012 at 4:33 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
On Mon, Jul 2, 2012 at 8:12 PM, Robert Haas robertmh...@gmail.com
wrote:
On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov
aekorot
to make it
more transparent.
--
With best regards,
Alexander Korotkov.
wchar2mb-0.4.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
doing original changes. This it probably ok. But, we
could do some heuristics: detect that sequential scan is cheaper because of
large amount of updates or deletes in one table.
--
With best regards,
Alexander Korotkov.
On Sun, Jul 1, 2012 at 3:11 PM, Alexander Korotkov aekorot...@gmail.comwrote:
1) Patches don't apply cleanly to head. So I used commit
bed88fceac04042f0105eb22a018a4f91d64400d as the base for patches, then all
the patches close to this apply cleanly. Regression tests pass OK, but it
seems
Fix for a small tipo (space lost)
From be61035d21512324aafd41074511625d97d17256 Mon Sep 17 00:00:00 2001
From: Alexander Lakhin exclus...@gmail.com
Date: Thu, 28 Jun 2012 12:10:25 +0400
Subject: Fix for a small tipo (space lost).
---
src/backend/utils/misc/guc.c |2 +-
1 file changed, 1
On Wed, Feb 22, 2012 at 5:56 PM, Alexander Korotkov aekorot...@gmail.comwrote:
Attached patch fixes GiST behaviour without altering operators behaviour.
I think we definitely should apply this patch before 9.2 release, because
it is a bug fix. Otherwise people will continue produce incorrect
On Thu, Jun 21, 2012 at 11:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14.06.2012 01:56, Alexander Korotkov wrote:
Hackers,
attached patch implements quad-tree on ranges. Some performance results in
comparison with current GiST indexing.
@@ -788,7 +774,7
On Thu, Jun 14, 2012 at 2:56 AM, Alexander Korotkov aekorot...@gmail.comwrote:
attached patch implements quad-tree on ranges. Some performance results in
comparison with current GiST indexing.
Index creation is slightly slower. Probably, it need some investigation.
Search queries on SP-GiST
that chances.
Obviously, it makes insertion more expensive. I need some more benchmarks
to measure it. Probably, we would need a user-visible option for cheaper
insert or less bloat.
--
With best regards,
Alexander Korotkov.
gist_choose_bloat-0.1.patch
Description: Binary data
--
Sent via
@ '[2011-08-10,2011-12-31)'::daterange)
Buffers: shared hit=3093 read=1034
Total runtime: 54.288 ms
(7 rows)
--
With best regards,
Alexander Korotkov.
range_spgist_quad-0.2.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, Jun 5, 2012 at 2:00 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Mon, May 28, 2012 at 1:46 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Alexander, do you still have
On Mon, May 28, 2012 at 1:46 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Alexander, do you still have the test environments and data lying around
that you used for GiST buffering testing
of average tuple size?
--
With best regards,
Alexander Korotkov.
GiST index build, backend was frequently crashed. After recovery
partially built index file was remain. Do we have some tool to detect such
dead files? If not, probably we need some?
--
With best regards,
Alexander Korotkov.
to understand without reverse engeneering it from code.
--
With best regards,
Alexander Korotkov.
dubious to be comparing to a block count
even disregarding the power function.
In this test we use avgIndexTuplesPerPage as estimate for number of child
index pages of one page. I think we can assume it to have blocks unit.
--
With best regards,
Alexander Korotkov.
On Wed, May 30, 2012 at 12:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Tue, May 29, 2012 at 11:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm looking at this, is the first test involving
effective_cache_size bulletproof either
worthwhile, not only because it
fixes the bug and makes the code simpler, but also on performance grounds.
Cool, seems that we've both simplier and faster implementation of finding
parent. Thanks!
Alexander, do you still have the test environments and data lying around
that you used for GiST
, then they are LC2.
If LB is in 0xf0 - 0xff range, then they are LCPRV2.
Thanks. I rewrote inverse conversion from pg_wchar to mule. New version of
patch is attached.
--
With best regards,
Alexander Korotkov.
wchar2mb-0.2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql
and
charsets, see pg_wchar.h.
Thanks for your comments. They clarify a lot.
But I still don't realize how can we distinguish IS_LCPRV2 and IS_LC2?
Isn't it possible for them to produce same pg_wchar?
--
With best regards,
Alexander Korotkov.
On Wed, May 23, 2012 at 1:26 AM, Bruce Momjian br...@momjian.us wrote:
On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
Improve GiST box and point index performance by producing better trees
with
less memory allocation overhead (Alexander Korotkov, Heikki Linnakangas
to occur after creating GISTBufferingInsertStack
but before split of A. The question is how to find this copy from C, hash?
--
With best regards,
Alexander Korotkov.
changes in this function which make inverse conversion possible.
--
With best regards,
Alexander Korotkov.
gist (t collate C)
WITH (fillfactor=10);
I'll continue debugging that, but it seems to be another, unrelated, bug.
Thanks for debugging and fixing that. I'm going to take a look on the
remaining bug.
--
With best regards,
Alexander Korotkov.
, the
question arises if we're going to measure ratio in tuples count or in
tuples size. Ratio in tuples size seems to be more desirable while ratio in
tuples count seems to be easier for user picksplit to follow.
--
With best regards,
Alexander Korotkov.
Improve GiST box and point index performance by producing better trees
with less memory allocation overhead (Alexander Korotkov, Heikki
Linnakangas, Kevin Grittner)
Is this note about following two commits?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h
On Wed, May 2, 2012 at 4:50 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 1, 2012 at 6:02 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
Right. When number of trigrams is big, it is slow to scan posting list of
all of them. The solution is this case is to exclude most
On Wed, May 2, 2012 at 5:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 2, 2012 at 9:35 AM, Alexander Korotkov aekorot...@gmail.com
wrote:
Imagine we've two queries:
1) SELECT * FROM tbl WHERE col LIKE '%abcd%';
2) SELECT * FROM tbl WHERE col LIKE '%abcdefghijk
such datasets?
Also, I did some optimizations in algorithm. Automaton analysis stage
should become less CPU and memory consuming. I'll publish new version soon.
--
With best regards,
Alexander Korotkov.
such decision, but it doesn't seem to be feasible
to get it using current GIN interface.
Probably you have some comments on idea of conversion from pg_wchar to
multibyte? Is it acceptable at all?
--
With best regards,
Alexander Korotkov.
in the same query.
--
With best regards,
Alexander Korotkov.
.
--
With best regards,
Alexander Korotkov.
wchar2mb-0.1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
which looks like extension of Jeff Davis proposal to
the multidimensional case. It is Plane Sweep and External Plane Sweep
methods. However, it might use sophisticated data structures for the
sweep. And I believe it should use it for good performance.
--
With best regards,
Alexander Korotkov.
On Tue, Apr 17, 2012 at 12:12 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-04-16 at 16:22 +0400, Alexander Korotkov wrote:
There is a good overview article about spatial joins.
http://www.cs.umd.edu/users/hjs/pubs/jacoxtods07.pdf
Thank you, that's exactly the kind of overview I
On Mon, Mar 12, 2012 at 3:50 PM, Alexander Korotkov aekorot...@gmail.comwrote:
I believe that attached version of patch can be backpatched. It fixes this
problem without altering of index building procedure. It just makes checks
in internal pages softener enough to compensate effect
On Thu, Mar 8, 2012 at 4:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
True. If (max count - min count + 1) is small, enumerating of frequencies
is both more compact and more precise representation. Simultaneously,
if (max count - min count + 1
I believe that attached version of patch can be backpatched. It fixes this
problem without altering of index building procedure. It just makes checks
in internal pages softener enough to compensate effect of gist_box_same
implementation.
--
With best regards,
Alexander Korotkov.
*** a/src
On 03/07/2012 08:03 PM, Peter Eisentraut wrote:
On ons, 2012-03-07 at 18:31 +0200, Alex Shulgin wrote:
I figured that adding this right into src/interfaces/libpq is
polluting the source dir, so I've used src/test instead.
I would prefer src/interfaces/libpq/test, to keep it close to the
On 03/07/2012 09:16 PM, Alexander Shulgin wrote:
I would prefer src/interfaces/libpq/test, to keep it close to the code.
Hm, actually that makes more sense and is not unprecedented (I see ecpg
has it's own 'test' subdir.) Apparently I was under false impression
that all regression tests
On 03/06/2012 01:09 AM, Peter Eisentraut wrote:
On ons, 2012-02-22 at 12:26 -0500, Greg Smith wrote:
I started collecting up all the variants that do work as an
initial shell script regression test, so that changes don't break
something that already works. Here are all the variations that
statkind and statistics slot. Probably, you've
better ideas?
--
With best regards,
Alexander Korotkov.
array of
unique DEC and it's frequency.
--
With best regards,
Alexander Korotkov.
*** a/src/backend/utils/adt/array_typanalyze.c
--- b/src/backend/utils/adt/array_typanalyze.c
***
*** 581,587 compute_array_stats(VacAttrStats *stats, AnalyzeAttrFetchFunc fetchfunc
case rough estimate is quite accurate. But in most
part of cases it behaves really bad. It is why I started to invent
calc_distr and etc. So, I think return DEFAULT_CONTAIN_SEL is OK unless
we've some better ideas.
--
With best regards,
Alexander Korotkov.
On Thu, Mar 1, 2012 at 1:19 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Thu, Mar 1, 2012 at 1:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That seems like a pretty narrow, uncommon use-case. Also, to get
accurate stats for such queries that way, you'd need really enormous
histograms
/msg00780.php
Probably, btree statistics really does matter for some sort of arrays? For
example, arrays representing paths in the tree. We could request a subtree
in a range query on such arrays.
--
With best regards,
Alexander Korotkov.
On Thu, Mar 1, 2012 at 1:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Thu, Mar 1, 2012 at 12:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I am starting to look at this patch now. I'm wondering exactly why the
decision was made to continue
On 02/24/2012 03:18 PM, Florian Weimer wrote:
* Alex Shulgin:
It's ugly, but it's standard practice, and seems better than a separate
-d parameter (which sort of defeats the purpose of URIs).
Hm, do you see anything what's wrong with ?dbname=other if you don't
like a separate -d?
It's not
On 02/25/2012 09:37 PM, Cédric Villemain wrote:
I've not followed all the mails about this feature but I don't find it is a
nice syntax too.
?dbname=other looks like dbname is an argument, but dbname is a requirement
for postgresql connexion.
Ugh, not really. AFAIK, dbname is a connection
Attached patch fixes GiST behaviour without altering operators behaviour.
--
With best regards,
Alexander Korotkov.
*** a/src/backend/access/gist/gistproc.c
--- b/src/backend/access/gist/gistproc.c
***
*** 836,842 gist_box_picksplit(PG_FUNCTION_ARGS)
}
/*
! * Equality
On Thu, Feb 16, 2012 at 11:43 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
Described differences leads to incorrect behaviour of GiST index.
The question is: what is correct way to fix it? Should on_pb also use FP*
or consistent method should behave like on_pb?
Any comments
I'm spending my time on the right things).
FYI, I found myself to be eligible for this year. So, if PostgreSQL will
participate this year, I'll do some proposals on indexing.
--
With best regards,
Alexander Korotkov.
On Wed, Feb 15, 2012 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So, I think we should go with your original fix and simply do nothing
On Mon, Feb 20, 2012 at 7:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Thu, Feb 16, 2012 at 11:43 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
Described differences leads to incorrect behaviour of GiST index.
The question is: what
empty flag was introduced. This contain
empty flag indicates that underlying value can be empty. So, this flag is
set when union with empty range or other range with this flag set. It's
likely you need similar flag for each dimension.
--
With best regards,
Alexander Korotkov.
On Fri, Feb 17, 2012 at 11:32 PM, Jay Levitt jay.lev...@gmail.com wrote:
Alexander Korotkov wrote:
On Fri, Feb 17, 2012 at 11:00 PM, Jay Levitt jay.lev...@gmail.com
mailto:jay.lev...@gmail.com wrote:
At first I thought this posed a challenge for union; if I have these
points
similarity search using GiST (for example, sets,
strings etc.).
--
With best regards,
Alexander Korotkov.
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That
should
be true because we're
buffers for
the new sibling pages. In the final emptying phase, that's a waste of time,
the buffers we create will never be used, and even before that I think it's
better to create the buffers lazily.
I agree.
--
With best regards,
Alexander Korotkov.
return from the function instead of
triggering error. Patch is attached.
--
With best regards,
Alexander Korotkov.
*** a/src/backend/access/gist/gistbuildbuffers.c
--- b/src/backend/access/gist/gistbuildbuffers.c
***
*** 607,617 gistRelocateBuildBuffersOnSplit(GISTBuildBuffers
with following setting:
effective_cache_size = 3734MB
because buffering GiST index build just shouldn't turn on in this case when
index fits to cache. I'm goint to take a detailed look on this.
--
With best regards,
Alexander Korotkov.
that.
-
With best regards,
Alexander Korotkov.
.
So, users could just tune effective_cache_size for gist index build on high
concurrency.
--
With best regards,
Alexander Korotkov.
per loop down to about 1.5..13 ms per loop.
That seems to indicate that the index distribution is better, with more
queries returning quickly.
So, great work Alexander! Very convincing results.
Great! Thank you for reviewing this patch!
Marking ready for committer, but please apply my comment
, we'd need to make sure it terminated at
some point, but splitting the common entries does seem like a smaller
version of the original problem. Thoughts?
That was a bug. Actually, no abs is needed. Indeed it doesn't affect
result significantly.
-
With best regards,
Alexander Korotkov
, please post another update.
Changes looks reasonable for me. Thanks!
--
With best regards,
Alexander Korotkov.
of elements.
--
With best regards,
Alexander Korotkov.
arrayanalyze-0.12.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bug, I think, when running with 'set
enable_seqscan=off' in combination
with a too-large regex:
Thanks for pointing. Will be fixed.
--
With best regards,
Alexander Korotkov.
slow (because index scan itself is breakable). So, it just
shouldn't work so long.
--
With best regards,
Alexander Korotkov.
On Fri, Jan 20, 2012 at 12:54 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Fri, Jan 20, 2012 at 12:30 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Apart from that, the multibyte issue seems like the big one. Any way
around that?
Conversion of pg_wchar
function in pg_wchar_tbl which converts pg_wchar back to multibyte
character is possible solution?
--
With best regards,
Alexander Korotkov.
to pg_wchar
is possible from these encodings?
--
With best regards,
Alexander Korotkov.
On Fri, Jan 20, 2012 at 1:07 AM, Alexander Korotkov aekorot...@gmail.comwrote:
What does last 7 zeros in the first column means? No conversion to
pg_wchar is possible from these encodings?
Uh, I see. These encodings is not supported as server encodings.
--
With best regards,
Alexander
that one different?
Oh, I didn't update all array types in 2 tries :) Fixed.
--
With best regards,
Alexander Korotkov.
arrayanalyze-0.11.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
At this point I feel that this new functionality might be a bit
overkill for postgres, maybe it's better to stay lean and mean rather
than add a controversial feature like this.
I also agree that a more general replication timeout variable would be
more useful to a larger audience but that would
of
elements. Substracting mcelem frequencies from avg_length we have summ of
frequencies of non-mcelem elements.
--
With best regards,
Alexander Korotkov.
arrayanalyze-0.9.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
.).
--
With best regards,
Alexander Korotkov.
arrayanalyze-0.8.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 4, 2012 at 12:33 AM, Noah Misch n...@leadboat.com wrote:
On Wed, Jan 04, 2012 at 12:09:16AM +0400, Alexander Korotkov wrote:
Thanks for your great work on reviewing this patch. Now I'm trying to
find
memory corruption bug. Unfortunately it doesn't appears on my system. Can
you
Okay,
Here’s version 3 then, which piggy-backs on the existing flag :
synchronous_commit = on | off | local | fallback
Where “fallback” now means “fall back from sync replication when no
(suitable) standbys are connected”.
This was done on input from Guillaume Lelarge.
That said, I agree
Hello and thank you for your feedback I appreciate it.
Updated patch : sync-standalone-v2.patch
I am sorry to be spamming the list but I just cleaned it up a little
bit, wrote better comments and tried to move most of the logic into
syncrep.c since that's where it belongs anyway and also fixed a
Interesting discussion!
Basically I like this whole idea, but I'd like to know why do you think
this functionality is required?
How should a synchronous master handle the situation where all
standbys have failed ?
Well, I think this is one of those cases where you could argue either
way.
Hmm,
I suppose this conversation would lend itself better to a whiteboard
or a maybe over a few beers instead of via e-mail ...
Basically I like this whole idea, but I'd like to know why do you think
this functionality is required?
How should a synchronous master handle the situation where
On Mon, Dec 26, 2011 at 5:18 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
Basically I like this whole idea, but I'd like to know why do you
Hi all,
I’m new here so maybe someone else already has this in the works ?
Anyway, proposed change/patch :
Add a new parameter :
synchronous_standalone_master = on | off
To control whether a master configured with synchronous_commit = on is
allowed to stop waiting for standby WAL sync when
regards,
Alexander Korotkov.
/RegularPapers/paper16.pdf
Any thoughts?
-
With best regards,
Alexander Korotkov.
Hi!
On Wed, Nov 16, 2011 at 1:43 AM, Nathan Boley npbo...@gmail.com wrote:
FYI, I've added myself as the reviewer for the current commitfest.
How is going review now?
--
With best regards,
Alexander Korotkov.
. Ideally
it should be real-life set of queries, but it also could be your
presentation of what are typical queries for such datasets.
Thanks!
-
With best regards,
Alexander Korotkov.
Excerpts from Greg Smith's message of Wed Dec 14 02:54:14 +0200 2011:
Initial quick review of your patch: you suggested this as the general form:
psql -d postgresql://user@pw:host:port/dbname?param1=value1param2=value2...
That's presumably supposed to be:
psql -d
,
Alexander Korotkov.
rangetypegist-0.5.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Dec 10, 2011 at 6:14 PM, Greg Smith g...@2ndquadrant.com wrote:
On 12/02/2011 06:48 AM, Alexander Korotkov wrote:
Rebased with head.
Could you comment a little more on what changed? There were a couple of
areas Tom commented on:
-General code fixes
Expensibe usage of Max macro
compromise might be to accept either one. AIUI, part of
what Alexander was aiming for here was to unite the clans, so to
speak, and it would seem a bit unfriendly (and certainly
counter-productive as regards that goal) to pull the rug out from him
by refusing to support that syntax over what
Hello Hackers,
Attached is a work-in-progress patch for URI connection string syntax support
in libpq. The recent discussion (also pointing to the original one) is here:
http://archives.postgresql.org/message-id/132180-sup-1235@moon
The patch adds support for the following syntax in
Excerpts from Daniel Farina's message of Mon Dec 05 11:56:19 +0200 2011:
I think the current direction is fine, although as Robert Haas has
said, I am not really at all inclined to view JDBC compatibility as
any kind of a plus. JDBC URLs are weird, and do the drivers actually
link libpq
Excerpts from Daniel Farina's message of Fri Dec 09 23:04:26 +0200 2011:
I guess if I move the parenthetical grouping of logic around, what you
are probably intending to say is everyone except this one ecosystem
does the normal thing, so we have an opportunity to Unite The Clans,
by
Rebased with head.
--
With best regards,
Alexander Korotkov.
rangetypegist-0.4.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
801 - 900 of 1172 matches
Mail list logo
