64
postgresql10-10.0-20170406_1PGDG.rhel7.1.x86_64
postgresql10-contrib-10.0-20170406_1PGDG.rhel7.1.x86_64
postgresql10-server-10.0-20170406_1PGDG.rhel7.1.x86_64
postgresql10-libs-10.0-20170406_1PGDG.rhel7.1.x86_64
postgresql10-debuginfo-10.0-20170406_1PGDG.rhel7.1.x86_64
thanks
-Mark
it would appear that it didn't restart when I thought it had with the
service command.
apologies, I'm not able to reproduce anymore after restarting things.
On Thu, Apr 6, 2017 at 11:27 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > mark wrote:
> >> m=# creat
and I was thinking it was a psycopg2
problem, but seems there are issues with the internal counters in pg as
well for tracking "large" changes.
thanks,
Mark
On Sun, Feb 2, 2014 at 9:12 AM, Tom Lane wrote:
> Vik Fearing writes:
> > Without re-doing the work, my IRC logs sho
I could
well be looking in the wrong place, apologies if I've just been too
blind to see it.
Can anyone help?
Thanks,
Mark.
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
erstand that smlar is very new, not even a contrib yet, but was told I
might as well throw this out to this list.
If anyone wants more details please let me know and I will try and get them
to you.
..: Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Tuesday, June 05, 2012 9:22 PM
> To: mark
> Cc: 'pgsql-hackers'
> Subject: Re: [HACKERS] issue with smlar exension and gist index
> creation (9.2Beta1)
>
> "mark" wr
On Fri, Nov 12, 2010 at 12:45 AM, Gabriele Bartolini
wrote:
> Hi Mark,
>
> Il 12/11/10 03:31, mark ha scritto:
>>
>> I have listed what I think I will be doing with regards to initdb. if
>> anyone
>> sees problems with the following mixture during my dump -> i
> "put a C-locale index on the column", but text_pattern_ops is the way to
> do it today.
>
> regards, tom lane
>
Ok I hear you loud and clear.I am going to eat the overhead until
I get to 9.0.1, currently on 8.3.X in some places.
I will e
Could somebody explain me on which methods is based ts_rank and how it works?
I would appreciate some articles, if exist.
Thanks a lot for reply.
Mark
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/ts-rank-tp4384120p4384120.html
Sent from the PostgreSQL - hackers
>There's some potentially useful information here:
>http://www.postgresql.org/docs/9.0/interactive/textsearch-controls.html#TEXTSEARCH-RANKING
Thanks for reply. I was reading the documentation of PostgreSQL, but there
it is not written the name of the used methods. Everywhere there is written,
tha
ever chosen to use the BSD license as a template for any
of my software - but if I did, the University of Berkeley cannot change
the terms of *my* software. The University of Berkeley can only change
the terms of software actually owned by the University of Berkeley.
Cheers,
mark
--
[EMAIL
diately follows the "%".
Have you considered a two pass approach? First pass - match on bytes.
Only if you find a match with the first pass, start a second pass to
do a 'safe' check?
Are there optimizations to recognize whether the index was created as
lower(field) or upper(
ter criteria for a properly designed select statement by
a like with high selectivity? The only time I have ever used like is
when I expect low selectivity. Is there a reasonable case I am missing?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED
e effect of inserts always being to the end of
the index. While this might pack tightly, wouldn't this hurt
concurrency? Random access vs sequential performance. For UUID, I
would value random access before sequential performance. Why would
anybody scan UUID through the index in "sequential&
E comparator to be the fastest
comparison possible, to allow the quickest scanning of the index entries.
I don't believe fragmentation is a serious issue, and I believe there are
concurrency benefits to inserting into different index pages, rather than
always adding to the end.
Cheers,
mark
-
ense of other users. The minimal expense comes from the more
complicated comparator function, and the confusion of any who see
their non-UUIDv1 UUID's sorted by some apparently arbitrary scheme
that seems to have a history of assuming that UUIDv1 will be used.
Cheers,
mark
--
[EMAI
ields clear. It gives flexibility to create the index on either/or.
For read-only data, I've taken to using the SHA1 sum of the data as
the unique id instead of UUID or SEQUENCE. Works pretty good... :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED
and it's source
code. Can anyone please offer some advice or suggestions?
Thanks,
Mark
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
unnecessary post.
On Wednesday 11 July 2001 09:16, Mark wrote:
> Quick rundown of our configuration:
> Red Hat 7.1 (no changes or extras added by us)
> Postgresql 7.1.2 and CVS HEAD from 07/10/2001
> 3.8 gb database size
>
> I included two pgsql versions because this happens on bo
te an include that I would be able to place
in the DECLARE SECTION and also use in the SELECT statements.
All of these methods are based upon my prior experience with embedded
sql, so if Postgres has a better method, or something new has come up,
please let me know.
Thanks!
Are people comfortable in believing that tables that do not change
are a valuable point to consider for caching?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . .
or query results stored in cache along with the
transaction numbers that would let us know whether either is valid.
Consistency is very valuable to me. If it wasn't for memcache being
hundreds or more times faster, I wouldn't use it in the cases I do.
It can be dang
e, and there are many
> frameworks that handle the burden of maintaining both for you.
Consistency and memcached, *are* mutually exclusive.
memcached provides no mechanisms for consistency.
Close may good enough for
ure what this would save. If the table is read-only, there
shouldn't be writes happening. If it's small, and frequently accessed,
it should fit in the buffer cache.
None of this avoids the cost of query planning, or query execution.
Cheers,
mark
--
[EMAIL P
FOR UPDATE is only useful if I'm going to do SELECT. If I am
using memcache, one would presume that I am using it in place of
SELECT, to improve performance. If I'm going to SELECT and then
memcache, I haven't gained anything.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL
e pages. For example, why not be able to
hint to PostgreSQL that a disk-based table should be considered a
priority to keep in RAM. That way, PostgreSQL would avoid pushing
pages from this table out.
I'm not convinced that this would be a gain, though. I highly expect
that an LRU rule i
t it allows lowering the amount of write activity
> to the user_session table by 95% with no loss of information we care about.
> Of course, if you are using a Java or .NET application server, it probably
> provides the above functionality itself.
Agree.
Cheers,
mark
--
[
current cache algorithm, it should be fixed.
What is the problem with it?
I think the memcache people are thinking that the cost of PostgreSQL is
about the disk. Although the disk plays a part, I'm pretty sure it's
only a fraction. Not providing transaction guarantees, not providing an
SQL le
for a
short time. I'm compromising accuracy for efficiency.
The thing about all of this is, if what memcache is doing could be
done with consistency? PostgreSQL would probably already be doing it
right now...
Cheers,
mark
--
[EM
down. Nobody is willing
to tackle it, because it seems like a lot of effort, for a problem that
can be mostly solved by application-side caching.
It's a subject that interests me - but it would take a lot of time, and
that's the thing that few of us have. Time sucks. :-)
Cheers,
m
olution: if the machine reboots, the content of
> the tablespace will disappear, requiring manual administrator
> intervention to get Postgres running again.
It's enough to show whether disk read/write is the crux of this issue
or not. I suspect not.
Anybody have numbers?
Cheers,
ma
reSQL unable to max out the I/O bandwidth? Where? Why?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__
the scenarios and
configuration of the person who wrote it, did not show significant
improvement.
You have PostgreSQL on Windows with EMC with async I/O support to
test with?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
rmed before posting. :-)
So yeah - not too impressive...
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. .
page boundaries.
> But not that often, with full_page_writes = off. So we could get away
> with just CRC checking the page-spanning ones and mark the records to
> show whether they have been CRC checked or not and need to be rechecked
> at recovery time. That would reduce the CRC o
unlike tuples, WAL records can and do cross page boundaries.
> > > But not that often, with full_page_writes = off. So we could get away
> > > with just CRC checking the page-spanning ones and mark the records to
> > > show whether they have been CRC checked or not and need
I possess, and a
password that I know or have stored in a file.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__.
other issue :)
Isn't NFSv4 a big application that uses Kerberos? I seem to recall that
AFS may have been a large user as well.
The only reason it isn't widely used is because companies are slow to
change. We still use NIS for host names in too many places!
Cheers,
mark
--
[EMAIL PROTECT
For example, a USB key or digital display that I
> > possess, and a password that I know or have stored in a file.
> Well, you know how to deal with passwords and authentication. Most users
> don't. Therefor using things like smartcard+PIN can *both* increase
> security *and* make t
job people.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/|_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__
wer 8.1 times. :-(
I will have to investigate. The generated plan is more complex after
'analyze'...
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. ._
st implement the change described in the
documentation to allow their loadable modules to work properly in 8.2".
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
_
REJECT rule is used?
I don't know about the nbtinsert.c warnings. It looks like part of a
structure is initialized, and then the structure is used. A little odd.
I've included them all below. Pretty few for an open source project. :-)
Cheers,
mark
gcc -O3 -march=athlon64 -Wall -Wmissing-p
e. :-)
> The "find_rule" gripe is really a flex bug :-( ... not easy to avoid.
*nod*
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
:-)
I wonder what would happen if somebody implemented automatic index
exclusion conditions after use of an INDEX proved to be in the realm
of the worst case scenario? :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
.
restriction list, and prune the now wasted index records.
Sorry for inserting a silly joke in a serious discussion... :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ .
gliness
as OpenSSL/C code that needs to load the encrypted private key and
client/server x509 certificates from a Java Keystore (JKS)... Total
fun... :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAI
erves to be challenged.
There are other elements that could be included in the business case.
For example, the documentation for GNUTLS seems to be significantly
better.
I don't like fear mongering. It smells like FUD. :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PR
ut authentication
> mechanisms, operating systems, or even client libraries.
They're entirely different discussions. One is about politics. One is
about practical application.
With regard to practical application, I agree with you.
With regard to giving in to legal FUD, I feel it is my
t practical argument,
>but not sure it'd hold up when that'd basically make all of Debian
>exempt since it can all be considered 'part of the OS'...)
My opinion: Same as a). The responsibi
On Fri, Dec 29, 2006 at 08:31:34PM +1300, Mark Kirkwood wrote:
> [EMAIL PROTECTED] wrote:
> >I will try again. It is a difficult subject for many.
> >GPL software derived from PostgreSQL must honour the restrictions defined
> >by the PostgreSQL (BSD) license.
> >GPL so
y for fault in what is said, purposefully choosing not
to assimilate the other persons contribution. It's called the "I am right
you are wrong" syndrome, and I'm not exempt from it.
I hope I provided val
under heavy development.
I don't find the reasons too compelling - but they are points to
consider.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Nei
fields, and use only the private key / public key / fingerprint
of public certificate, which would match your use of PGP keys... :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. ._
interpretation, but qualified several times that Debian may be incorrect.
I spent quite a lot of thread space on exactly this issue - that forcing
an additional license to be imposed on the user, is indeed an additional
restriction. People either get it or they don't. It would either sta
proven an issue exists. The only way to prove it would be
for an actual court case to set the precident.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
s not required for the later bytes to be '\0'.
I assume Peter is only changing the provably good uses? :-)
Cheers,
mark
> Peter Eisentraut wrote:
> > Log Message:
> > ---
> > StrNCpy -> strlcpy (not complete)
> >
> > Mo
unds appealing to me) - could
it be done with just a 1 byte list? 24 instead of 23 for the tuple size.
I'll try to catch up at some point. :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._
Hey all:
This is a randomly inserted distraction to tell you that I really like to
read about these ideas. No input from myself at this point. I'm happy with
the direction you are taking.
Thanks,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROT
sed today.
I see it buying increased performance for rows that are frequently
updated. If it can delay modifying the indices to only once every 10
or more updates, it seems to me that the improvement should be
significant. Perhaps PostgreSQL could be used for page hit counters
again... :-)
Chee
se doesn't seem like
good value for the return.
Simpler analysis results in easier to optimize code for the compiler,
and less complexity stored on disk.
Please remove 2B. :-)
Cheers,
mark
--
[EMAIL PROTE
HOT-update chain. Resetting the HOT-updated
> status of the root tuple helps to mark the index entry LP_DELETE
> once the entire HOT-update chain is dead.
> ...
For some reason this paragraph raised a query in my mind. Will we
be able to toggle this new "hot update" code at co
ility, I would far prefer that. Can you say "I want change
2 followed by change 3" with checkboxes, a live final version to view, and
the ability to manually type or adjust lines in the final version to view?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
ding with me to be
> allowed to go back to CVS.
This shouldn't be a religious discussion - but I can't let the above go.
Anybody who prefers CVS over ClearCase for any reasons *other* than
financial reasons - doesn't understand SCM.
CVS is pretty close to the bottom for
the data, searching for a dozen
of these attributes requires either querying all attributes, where
the attributes could be scattered throughout the table, or querying
them one by one, which is worse.
If there was an efficient way to do this for both of my use cases,
I would be stro
is more useful for your application, you can't have
> your cake and eat it too.
No. Another reasonable conclusion is that the answer is not simple. This
doesn't mean the answer is undesirable. It means that people need more
time. :-)
I prefer abstractions, especially if they
On Fri, Jun 23, 2006 at 10:24:06AM -0400, Alvaro Herrera wrote:
> Mark Woodward wrote:
> > > In case of the number of actively modified rows being in only tens or
> > > low hundreds of thousands of rows, (i.e. the modified set fits in
> > > memory) the continuous v
s on one of the aspects?
I want to contribute soon, and this is the sort of thing that interests me -
but I still don't have time yet, and there would be no guarantee that I
succeeded. Somebody else? :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMA
ed? You
> must have a big table.
Jan: Who on the list has claimed that nothing is broken and nothing needs
to be improved? Are you making this claim?
Shutting down ideas is not constructive. Encouraging those with ideas to
step up and do mor
use in core,
with few or no uses, including functions to operate on these types,
and no UUID type... Hehe... To me, that's irony... :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .
for a year or so. I don't
believe either of us have bothered to market it. Each time it comes up,
a number of people on this list shut it down, and it doesn't seem worth
the effort to convince them otherwise. They can have their ivory tower,
and I
use
> > and we can make it portable enough, I think there is a good case for
> > including it.
> Well, since Mark has one, how about we consider adding it in?
> If nothing else, can you please put your stuff on pgFoundry so others
> can find it, Mark?
It was written by Nathan W
SQL
'bindings'. I may try and contact the author of the OSSP UUID and
see whether any changes we have that he does not, can be rolled
into his version...
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__
.
If it was a full data type - could it be passed around in memory by
value, and not as a pointer? Or is 16 bytes too big to pass around by
value?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ .
type generators yet,
> so I'm unsure whether a patch creating one would be accepted for core.
Not sure what I think of this. I suppose the intention would be for it
to work for lengths other than 16? I can see people wanting to use such
a generalized function for char as well as byte
x27; implementation should loop if 2) fails and
restart the operation.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__
nary data.
e) Generic n-byte binary data type generator. Not sure of feasibility
of this at this point. See thread.
2) According to your answer in 1), the added 128-bit type should be:
a) In core first.
b) In contrib first.
c) In pgfoundry first.
Thanks,
mark
--
A really low fillfactor could be a good idea in a heavily updated
> table --- at least, I don't think we have any evidence to prove
> that it's not sane to want a fillfactor below 50%.
If there was a way of packing relations tighter, allowing much lower
fillfactors sh
e PostgreSQL to use a
> > smaller fillfactor while still allowing people to optimize those of
> > their tables that would benefit from a higher fillfactor once they
> > become mostly static?
> Isn't it sufficient to change the fillfactor and REINDEX?
I've never tried that
me this taste. Please
help PostgreSQL not be on this list by pruning dead projects, or
poor quality projects from the public image. It's EMBARASSING! :-)
Thanks.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
tied to the backend API, and there is thousands of lines of unnecessary
code.
Now you are going to make me try them both out. I have not tried either.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . .
bstractions on top,
or wants to provide thousands of pages of documentation - this is their
choice, but would be distributed separate from the core, but would be
simple to plug in.
Am I just spitting crazy talk, or is this making sense?
Cheers,
mark
the fact.
If this is just crazy talk - please stop me.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/|_ |\/| | |_ | |/ |_ |
| |
e for all rows that have a particular attribute type with a
particular value, it's a seqscan right now. With the bitmap scanner,
knowing which rows to skip to immediately is readily available.
Will it be w
#x27;t as large as many of yours. Most or all of them
will fit in 1 Gbytes of RAM. The I/O cost isn't substantial for these,
but the WHERE clause might be.
But yeah - we don't know. Waste of code or performance boost.
Ch
ear on what these are, whether they apply
to production use scenarios, or whether b-tree could not be optimized
to be better.
I support you - I want to see these great things for myself.
But irrefutable? Irrefutable is not true. :-)
C
om the article, though, is that DB2 is more modularized than
PostgreSQL, however, it has concurrency issues. Is this true? Anybody allowed
to comment on the peformance of small-sized (~1 million rows) databases?
I'm not seeing a compelling reason to switch.
Cheers,
mark
--
[EMAIL PROTECTE
;m not sure that it warrants being changed, though. Storing mixed
precision values in a column and expecting the database to understand
rounding rules does not appeal to me. Too magical.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] /
t;not equal" result.
And it is wrong - because they are equal. But 1.0 is also equal to 1.01.
We shouldn't go there. :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EM
put together. Then an insertion of '1' would have to re-group them
all together, making the B-Tree ineffective.
So - taking back what I say above.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [E
ld be investigated, for however short, to
see whether it is intentional or not.
For example, if the memory is allocated within a loop, or which the bounds
are not fixed, even a short running program can benefit from being fixed.
If it is just configuration data represented in memory, created
els. I'm also not sure on what to
expect for results, as the territory is still new. 64-bit processors
have existed for a while, but 32-bit processors have been the popular
choice, making 64-bit support an after thought?
Cheers,
mark
--
[EMAIL
forms.
What application were you thinking of that takes full advantage of 64-bit,
making the 64-bit application much significantly faster than the 32-bit
application? The only area I am aware of, is video processing.
It's often a surprise to people that an upgrade to 64-bit, regardless of
C
g it as a valid question.
Please don't write it off, but it is fine to say "not yet, we have more
important things to work on".
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . ._
#x27;m not claiming that I have the answers. I am claiming that a few of
you share this weakness, and that an assumption that PostgreSQL is
designed for 64-bit would be incorrect. :-)
Cheers,
mark
--
[EMAIL PROT
moving buffers between OS cache
> and shared memory. On system with RAM below 2-3GB to difficult found
> serious gain of performance.
This is the main difference between PostgreSQL today - designed for
32-bit - when recompiled with a 64-bit compiler.
The additional registers are barel
e. :-)
You claimed that PostgreSQL is not tuned to a specific processor, and
relies on the kernel, the compiler, and libc to perform some tuning. I
agree with this as well.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTE
r is quite acceptable to me. It's not the original answer that
was given to the original poster though... :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_|
what will be
included in, say, PostgreSQL 8.2, without asking "what will be in
PostgreSQL 8.2?"
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . ._
cenarios you are hitting should be dealt with, possibly
in JDBC.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/|_ |\/| | |_ | |/ |_
1 - 100 of 1446 matches
Mail list logo
