On Wed, Oct 16, 2002 at 02:08:21PM -0400, Curtis Faith wrote:
>
> 2) Including the pros and cons of the feature/implementation and how close
> the group is to deciding whether something would be worth doing. - I can
> also do this.
The pros and cons of many such features have been discussed over
On Thu, 2002-10-17 at 00:10, Neil Conway wrote:
>
>
> Well, I'm not happy with defining _GNU_SOURCE, but I don't agree that
> just saying "it's a Perl problem" is a good answer. That may well be
> the case, but it doesn't change the fact that a lot of people are
> running 5.8.0, and will probabl
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8.
>
> Builds fine on HPUX 10.20 with Perl 5.8.0 and gcc 2.95.3.
It may also depend on the way Perl is configured. I've attached the
output of 'per
On Wed, 16 Oct 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Right now we assume \XXX is octal. We could support \x as hex because
> > \x isn't any special backslash character. However, no one has ever
> > asked for this. Does anyone else think this would be benficial?
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> It looks like NAME comparison uses strcmp (actually strncmp). So it'll
>> be numeric byte-code order.
>> There's no particular reason we couldn't make that be strcoll instead,
>> I suppose, except perhaps speed.
> But how will th
Neil Conway <[EMAIL PROTECTED]> writes:
> As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8.
Builds fine on HPUX 10.20 with Perl 5.8.0 and gcc 2.95.3.
> There's a thread about a similar topic on p5p:
> http:[EMAIL PROTECTED]/msg75480.html
This thread makes it sound lik
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Right now we assume \XXX is octal. We could support \x as hex because
> > \x isn't any special backslash character. However, no one has ever
> > asked for this. Does anyone else think this would be benficial?
>
> Well, it seems pr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Right now we assume \XXX is octal. We could support \x as hex because
> \x isn't any special backslash character. However, no one has ever
> asked for this. Does anyone else think this would be benficial?
Well, it seems pretty localized and harmless.
As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8. I
get the following compile error:
gcc -O2 -g -fpic -I. -I/usr/lib/perl/5.8.0/CORE -I../../../src/include -c -o
plperl.o plperl.c -MMD
In file included from /usr/lib/perl/5.8.0/CORE/op.h:480,
from /usr/lib/pe
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > According to the syntax diagram in the documenation, I can write
> > >
> > > COPY table TO STDOUT WITH BINARY OIDS;
> > >
> > > Shouldn't the "binary", being an adjective, be attached to something?
> >
> > Uh, it is attached to WITH?
>
> At
Bruce Momjian writes:
> > According to the syntax diagram in the documenation, I can write
> >
> > COPY table TO STDOUT WITH BINARY OIDS;
> >
> > Shouldn't the "binary", being an adjective, be attached to something?
>
> Uh, it is attached to WITH?
Attached to a noun phrase, like "mode" or "outpu
Tom Lane writes:
> > But alphabetical? According to whose definition of the alphabet?
>
> It looks like NAME comparison uses strcmp (actually strncmp). So it'll
> be numeric byte-code order.
>
> There's no particular reason we couldn't make that be strcoll instead,
> I suppose, except perhaps s
On Wed, 2002-10-16 at 23:08, Curtis Faith wrote:
> Bruce Momjian wrote:
> I tried to prepare as best I could before bringing anything forward to
> HACKERS. In particular, I read the last two years of archives with anything
> to do with the WAL log and looked at the current code, read the TODOs, re
On Wed, 2002-10-16 at 16:05, Rod Taylor wrote:
> On Wed, 2002-10-16 at 16:56, Robert Treat wrote:
> > Perhaps one could just create a "PostgreSQL Powertools" section on
> > techdocs, naming the packages and where to get them. This would
> > eliminate the need to maintain a package that just duplic
On Wednesday 16 October 2002 05:05 pm, Rod Taylor wrote:
> On Wed, 2002-10-16 at 16:56, Robert Treat wrote:
> > Perhaps one could just create a "PostgreSQL Powertools" section on
> > techdocs, naming the packages and where to get them. This would
> > eliminate the need to maintain a package that j
On Wed, 2002-10-16 at 16:56, Robert Treat wrote:
> Perhaps one could just create a "PostgreSQL Powertools" section on
> techdocs, naming the packages and where to get them. This would
> eliminate the need to maintain a package that just duplicates other
> packages...
Let ye-old package managers m
Perhaps one could just create a "PostgreSQL Powertools" section on
techdocs, naming the packages and where to get them. This would
eliminate the need to maintain a package that just duplicates other
packages...
Robert Treat
On Wed, 2002-10-16 at 16:00, Justin Clift wrote:
> > Thomas Swan wrote:
> Thomas Swan wrote:
>
> Justin Clift wrote:
> > Ok. Wonder if it's worth someone creating a "PostgreSQL Powertools"
> > type of package, that includes in one download all of these nifty
> > tools (pg_autotune, oid2name, etc) that would be beneficial to have
> > compiled and already available.
Justin Clift wrote:
"Marc G. Fournier" wrote:
Not going to happen ... there are oodles of "not big, but useful" pieces
of software out there that we could include ... but th epoint of Gborg is
you download the main repository, and then you go to gborg to look for the
add-ons you mi
The slashdot article:
http://slashdot.org/article.pl?sid=02/10/14/1720241&mode=nested&tid=95
The isoc page: http://www.isoc.org/dotorg/
the isoc proposal:
http://www.isoc.org/dotorg/10-1.shtml
the Oracle post:
http://forum.icann.org/org-eval/gartner-report/msg0.html
Good day.
On 16 O
Karl DeBisschop wrote:
> On Mon, 2002-10-14 at 16:14, scott.marlowe wrote:
>
>>It's on Slashdot, but there's only one post there that mentions the use of
>>Postgresql.
>>
>>On 14 Oct 2002, Robert Treat wrote:
>>
>>
>>>Yep, that's them. This is a big win from a PostgreSQL advocacy position,
>>>es
On Mon, 2002-10-14 at 16:14, scott.marlowe wrote:
> It's on Slashdot, but there's only one post there that mentions the use of
> Postgresql.
>
> On 14 Oct 2002, Robert Treat wrote:
>
> > Yep, that's them. This is a big win from a PostgreSQL advocacy position,
> > especially since oracle pr made
Bruce Momjian wrote:
> Let me add one more thing on this "thread". This is one email in a long
> list of "Oh, gee, you aren't using that wizz-bang new
> sync/thread/aio/raid/raw feature" discussion where someone shows up and
> wants to know why. Does anyone know how to address these, efficiently
On Wed, 2002-10-16 at 12:33, David Walker wrote:
> Vacuum full locks the whole table currently. I was thinking if you used a
> similar to a hard drive defragment that only 2 rows would need to be locked
> at a time. When you're done vacuum/defragmenting you shorten the file to
> discard the d
Right now we assume \XXX is octal. We could support \x as hex because
\x isn't any special backslash character. However, no one has ever
asked for this. Does anyone else think this would be benficial?
---
Igor Georgiev w
But doesn't the solution I offer present a possible work around? The
table wouldn't need to be locked (I think) until the first dead tuple
were located. After that, you would only keep the locks until you've
scanned X% of the table and shrunk as needed. The result, I think,
results in increment
1. Why i do
this:
I try to migrate a database with
a 200 tables from Sybase SQL Anywhere to PostgreSQL,
but SQL Anywhere escapes special
characters like a HEX values ( like \x0D \x2C . ).
PostgreSQL COPY FROM recognize
only OCT values ( lie \001 ... )
2. How-to it' easy :)))
Vacuum full locks the whole table currently. I was thinking if you used a
similar to a hard drive defragment that only 2 rows would need to be locked
at a time. When you're done vacuum/defragmenting you shorten the file to
discard the dead tuples that are located after your useful data. Ther
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Still, one could ask why we are expending extra cycles to make the
> >> timeout more accurate. Who the heck needs an accurate timeout on
> >> connect? Can you really give a use-case where the user won't have
> >
I will keep this in case we need it later. I think we worked around
this problem by having timeout == 1 set equal to 2 so we get at least
one second for the connection.
---
Denis A Ustimenko wrote:
> On Mon, Oct 14, 2002 a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Still, one could ask why we are expending extra cycles to make the
>> timeout more accurate. Who the heck needs an accurate timeout on
>> connect? Can you really give a use-case where the user won't have
>> picked a number out of the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, the new code has _three_ time() calls, rather than the old code
> > that I think only had two. I was going to mention it but I figured
> > time() was a pretty light system call, sort of like getpid().
> > I needed the additional
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, the new code has _three_ time() calls, rather than the old code
> > that I think only had two. I was going to mention it but I figured
> > time() was a pretty light system call, sort of like getpid().
> > I needed the additional
On Wed, 2002-10-16 at 16:37, Robert Treat wrote:
> I'm pretty sure BSD allows you to relicense derived code as you see fit.
> However, any derived project that was released GPL would have a hell of
> a time ever getting put back into the main source (short of
> relicensing).
Exactly. This is on
Karel Zak kirjutas K, 16.10.2002 kell 15:19:
>
> Hi,
>
> I have SQL query:
>
> SELECT * FROM ii WHERE i1='a' AND i2='b';
>
> There're indexes on i1 and i2. I know best solution is use one
> index on both (i1, i2).
>
> The EXPLAIN command show that optimalizer wants to use one index:
>
On Wed, 2002-10-16 at 04:34, Justin Clift wrote:
> Bruce Momjian wrote:
> > Anuradha Ratnaweera wrote:
>
> > > Nope. To keep the `original' code licence as it is and to release the
> > > changes GPL? Is the question sane at first place?
> >
> > That would be a pretty big mess, I think. People
On Wed, 2002-10-16 at 02:29, Gavin Sherry wrote:
> On 16 Oct 2002, Hannu Krosing wrote:
>
> > On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote:
> > > Hi all,
> > >
> > > I'm thinking that there is an improvement to vacuum which could be made
> > > for 7.4. VACUUM FULLing large, heavily updated ta
On Wed, 2002-10-16 at 01:27, Shridhar Daithankar wrote:
> Well, slow adoption rate is attributed to 'apache 1.3.x is good enough for us'
> syndrome, as far as I can see from news. Once linux distros start shipping with
> apache 2.x series *only*, the upgrade cycle will start rolling, I guess.
Hannu Krosing <[EMAIL PROTECTED]> writes:
> meaning to VACUUM FULL the whole table, but to work in small chunks and
> relaese all locks and let others access the tables between these ?
AFAICS this is impossible for VACUUM FULL. You can't let other accesses
in and then resume processing, because
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, the new code has _three_ time() calls, rather than the old code
> that I think only had two. I was going to mention it but I figured
> time() was a pretty light system call, sort of like getpid().
> I needed the additional time() calls so the compu
On Wed, Oct 16, 2002 at 09:25:37AM -0400, Rod Taylor wrote:
> On Wed, 2002-10-16 at 09:19, Karel Zak wrote:
> >
> > Hi,
> >
> > I have SQL query:
> >
> > SELECT * FROM ii WHERE i1='a' AND i2='b';
> >
> > There're indexes on i1 and i2. I know best solution is use one
> > index on both (i1,
On Wed, 2002-10-16 at 09:19, Karel Zak wrote:
>
> Hi,
>
> I have SQL query:
>
> SELECT * FROM ii WHERE i1='a' AND i2='b';
>
> There're indexes on i1 and i2. I know best solution is use one
> index on both (i1, i2).
>
> The EXPLAIN command show that optimalizer wants to use one index:
>
Hi,
I have SQL query:
SELECT * FROM ii WHERE i1='a' AND i2='b';
There're indexes on i1 and i2. I know best solution is use one
index on both (i1, i2).
The EXPLAIN command show that optimalizer wants to use one index:
test=# explain SELECT * FROM ii WHERE i1='a' AND i1='b';
This code work for me :
Connection db = DriverManager.getConnection(url,user,passwd);
PreparedStatement st = db.prepareStatement("begin;declare c1 cursor for
select * from a");
st.execute();
st = db.prepareStatement("fetch 100 in c1");
ResultSet rs = st.exe
> > > > To work
> > > > around this you can use explicit cursors (see the DECLARE CURSOR,
> > > > FETCH, and MOVE sql commands for postgres).
I'm unable to get this to work using the default distribution JDBC driver.
(7.2). Here's a code snippet
conn.setAutoCommit(false) ;
stmt.exe
On Mon, Oct 14, 2002 at 01:00:07AM -0400, Bruce Momjian wrote:
> Denis A Ustimenko wrote:
> > On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
> > > Denis A Ustimenko wrote:
> > > >>Bruce, why have all precise time calculations been droped out in 1.206?
> > > >>If there is no
> > > >>g
Bruce Momjian wrote:
> Anuradha Ratnaweera wrote:
> > Nope. To keep the `original' code licence as it is and to release the
> > changes GPL? Is the question sane at first place?
>
> That would be a pretty big mess, I think. People would add your patch
> to our BSD code and it would be GPL. I
>>>Peter Eisentraut said:
> Daniel Kalchev writes:
>
> > One would normally expect, that when DROP USER someuser is issued, all
> > associated data structures will be readjusted, especially ownership and ac
cess
> > rights.
>
> Perhaps, but the documentation states otherwise.
>
[..
On 16 Oct 2002, Hannu Krosing wrote:
> On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote:
> > Hi all,
> >
> > I'm thinking that there is an improvement to vacuum which could be made
> > for 7.4. VACUUM FULLing large, heavily updated tables is a pain. There's
> > very little an application can do t
49 matches
Mail list logo
