Re: [HACKERS] updateable cursors visibility

2003-03-25 Thread snpe
Hello Neil,
  I try example for Oracle jdbc 1.4 driver
  This is sample and results.
  I hope that is helps.

  If you want yet another example, please tell me.

regards
Haris Peco

/**
 * A simple sample to check the availability of scrollable result sets.
 *
 * Please use jdk1.2 or later version
 */

import java.sql.*;

public class ResultSetmy1
{
  public static void main(String[] args) throws SQLException
  {
// Load the Oracle JDBC driver
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());

String url = jdbc:oracle:thin:@spnew:1521:V9i;
try {
  String url1 = System.getProperty(JDBC_URL);
  if (url1 != null)
url = url1;
} catch (Exception e) {
  // If there is any security exception, ignore it
  // and use the default
}

// Connect to the database
// You can put a database name after the @ sign in the connection URL.
Connection conn =
  DriverManager.getConnection (url, scott, tiger);

// Get the metadata regarding this connection's database
DatabaseMetaData dbmd = conn.getMetaData();

// List all the possible result set types
int resultset_types[] = 
{
  ResultSet.TYPE_FORWARD_ONLY,
  ResultSet.TYPE_SCROLL_INSENSITIVE,
  ResultSet.TYPE_SCROLL_SENSITIVE 
};

// List all the possible result set concurrency types
int concurrency_types[] = 
{ 
  ResultSet.CONCUR_READ_ONLY,
  ResultSet.CONCUR_UPDATABLE 
};

// List the result set type names
String resultset_types_msg [] = 
{
  Forward only, 
  Scroll insensitive, 
  Scroll sensitive
};

// List the concurrency type names
String concurrency_types_msg[] = 
{ 
  Read only, 
  Updatable 
};

// Check the availability of the result type and concurrency type
for (int i=0; iresultset_types.length; i++)
{
  for (int j=0; jconcurrency_types.length; j++)
  {
int type = resultset_types[i];
int concurrency = concurrency_types[j];

System.out.println (Type: +resultset_types_msg[i]++
Concurrency: +concurrency_types_msg[j]);
System.out.println
  ();

// Return true if the result set type is supported
System.out.println (supportResultSetType: +
dbmd.supportsResultSetType(type));

// Return true if the result set type and concurrency type is supported
System.out.println (supportsResultSetConcurrency: +
dbmd.supportsResultSetConcurrency(type, concurrency));

// Return true if the result set's updates are visible
System.out.println (ownUpdatesAreVisible: +
dbmd.ownUpdatesAreVisible(type));

// Return true if the result set's deletions are visible
System.out.println (ownDeletesAreVisible: +
dbmd.ownDeletesAreVisible(type));

// Return true if the result set's insertions are visible
System.out.println (ownInsertAreVisible: +
dbmd.ownInsertsAreVisible(type));

// Return true if other's changes are visible
System.out.println (othersUpdatesAreVisible: +
dbmd.othersUpdatesAreVisible(type));

// Return true if other's deletions are visible
System.out.println (othersDeletesAreVisible: +
dbmd.othersDeletesAreVisible(type));

// Return true if other's insertions are visible
System.out.println (othersInsertsAreVisible: +
dbmd.othersInsertsAreVisible(type));

// Return true if ResultSet.rowUpdated() is supported
System.out.println (updatesAreDetected: +
dbmd.updatesAreDetected(type));

// Return true if ResultSet.rowDeleted() is supported
System.out.println (deletesAreDetected: +
dbmd.deletesAreDetected(type));

// Return true if ResultSet.rowInserted() is supported
System.out.println (insertsAreDetected: +
dbmd.insertsAreDetected(type));

System.out.println ();
  }
}

// Close the connection
conn.close();   
  }
}

This is results :

Type: Forward onlyConcurrency: Read only

supportResultSetType: true
supportsResultSetConcurrency: true
ownUpdatesAreVisible: false
ownDeletesAreVisible: false
ownInsertAreVisible: false
othersUpdatesAreVisible: false
othersDeletesAreVisible: false
othersInsertsAreVisible: false
updatesAreDetected: false
deletesAreDetected: false
insertsAreDetected: false

Type: Forward onlyConcurrency: Updatable

supportResultSetType: true
supportsResultSetConcurrency: true
ownUpdatesAreVisible: false
ownDeletesAreVisible: false

[HACKERS] Bison 1.875 now required.

2003-03-25 Thread Lee Kindness
For those using Linux, the RPMs at:

 http://services.csl.co.uk/postgresql/

are probably handy.

L.

Bruce Momjian writes:
  Sorry, I meant bison 1.875 is now required, not 1.85.
  
  -- 
Bruce Momjian|  http://candle.pha.pa.us
[EMAIL PROTECTED]   |  (610) 359-1001
+  If your life is a hard drive, |  13 Roberts Road
+  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
  


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] to_char(interval) --- done?

2003-03-25 Thread Josh Berkus
Karel,

  If I see this I must agree with Peter that to_char() is something
  other than interval to interval-as-string convertor. The current
  code use date/time as complex of date/time information _based_ on
  calendar practice --
  The other words: current to_char(interval) is interval to calendar
  date/time convertor.

Currently, yes.   The reason why I'm advocating for a change is:

1) I can't imagine of what use the current behavior could possibly be.  Is 
there anyone at all using the current output of to_char(interval)?

2) to_char() is also used for converting numeric values to strings.   It is 
not in some way tied to date/time from a schema perspective, although it may 
be codewise.

  I think we can do with the current to_char(interval):

 a) maintain it as interval to calendar date/time string convertor,
 b) if nobody wants to use it as a) we can delete it from sources
and don't waste our time with it and use our time to real
interval convertor.

This sounds reasonable to me.  I'll even do a survey on the SQL list to see if 
anyone there is using the current behavior.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


Re: [HACKERS] 7.4devel auth failed

2003-03-25 Thread Andreas Pflug
Ok Bruce,

I found out what's happening.
I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by 
default. When connecting locally over IP (pgaccess), hba is checked 
against IPV6 patterns in pg_hba.conf.
My pgadmin2 machine will connect with an IP4-to-6 mapped address of 
0::c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to 
dst-in.sin_addr.s_addr=0xc0a80002. On the other side, SockAddr_pton 
will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ff, and 
consequently rangeSockAddr will fail.

If your kernel isn't V6 enabled, the incoming socket will be AF_INET, 
and no conversion is done, that's why you don't get the problem.
To fix this, the [12]..[15] indices need to be reversed (for Intel). 
This might be machine specific... Maybe for all big-endian machines the 
current code is ok, and needs reversal for little-endian processors.
I wonder if the following is completely portable, could be:
dst-in.sin_addr.s_addr = *(in_addr_t*)(src-in4.sin6_addr.s6_addr+12);

Regards,
Andreas
PS Your mail host candle.pha.pa.us rejected this mail as spam?!?



Bruce Momjian wrote:

That's strange.  I just tested it here, and it worked.  I have IPv6 code
enabled. but no IPv6 in my kernel, so there are just IPv4 connections.
Can you peek in this funciton and see where it is failing:
	
	int
	rangeSockAddrAF_INET(const SockAddr *addr, const SockAddr *netaddr,
	 const SockAddr *netmask)
	{
	if (addr-sa.sa_family != AF_INET ||
	netaddr-sa.sa_family != AF_INET ||
	netmask-sa.sa_family != AF_INET)
	return 0;
	if (((addr-in.sin_addr.s_addr ^ netaddr-in.sin_addr.s_addr) 
	 netmask-in.sin_addr.s_addr) == 0)
	return 1;
	else
	return 0;
	}   

That is the IPv4 function.
   

 



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] IO scheduler vs PostgreSQL performance measurement

2003-03-25 Thread Nick Piggin
scott.marlowe wrote:

On Mon, 17 Mar 2003, Nick Piggin wrote:


Dear PostgreSQL hackers,
I am developing a disk IO scheduler for Linux and am aiming to
have it included in the stable 2.6 release. Due to its design,
performance regressions do appear, and are often more specific
to the workload in question than with other schedulers, hence
one has to go beyond the generic benchmarks.
Databases are one area of difficulty due to multi threaded IO
and sync writes.
I would appreciate it if you could give me a suggestion
for a not-too-difficult to set up or interpret PostgreSQL
benchmark with a reasonable running time ( an hour or so)
which I can add to my performance regression tests.
It would be good if this were to separately measure most
common types of PostgreSQL IO work, and from there I would
leave specific areas to those interested.
I apologise for asking when I could search, however I am
interested in something up to date and which developers on
this can agree on.
For quick and dirty testing under high parallel load, you can use pgbench, 
which comes with postgres.  

cd /usr/local/src/postgresql-7.3.x/contrib/pgbench
make
make install
pgbench -i
pgbench -c 4 -t 100
For more intense testing, look at OSDB the Open Source database benchmark 
suite:

http://osdb.sourceforge.net/



Thanks for the references. I'll do a few pgbench runs today comparing
different schedulers so I'll CC you the results if you like.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org


Re: [HACKERS] Threaded Python vs. PostGreSQL plpython

2003-03-25 Thread Mike Meyer
In [EMAIL PROTECTED], Shridhar Daithankar [EMAIL PROTECTED] typed:
 On 24 Mar 2003 at 11:45, Mike Meyer wrote:

Just to clarify, the current situation is that I have things working,
but I also have a libpython.so that isn't threaded. I'm not happy
about the latter, and worry about rebuilding an embedded applications
and suddenly having my threaded scripots quit working because it
picked up the wrong library. I also have problems in that some modules
I should be able to import with plpython don't, because they are
linked against the wrong libc.

  In [EMAIL PROTECTED], Shridhar Daithankar[EMAIL PROTECTED][EMAIL 
  PROTECTED] typed:
 Now if you link libpython.so against linuxthreads, it *should* work perfectly 
 with postgresql because linuxthreads library provides only thread functions. 
 libc.so has none of them. So there is no chance of collision and it *should* 
 work.
 Anyway this is just to get things linked against and running. You can not run 
 threaded python apps with such a library because libc against which it is 
 linked is not threaded or thread safe.

So this would be similar to my current solution - my real python would
be threaded and linked against libc_r, and I'd have a special
libpython.so that looked like it could be threaded, but in reality
couldn't because it uses linuxthreads and a not-thread-safe libc. This
is not an improvement - in fact, I'd say it's worse.

 OTOH, you can link postgresql and libpython.so with libc_r. That should work as 
 well and you can use threads in python too. I would recommend this approach.

This was my second choice. I was hoping that someone would tell me
this was safe before I went to the trouble of trying it. Well, I was
hoping someone had a better solution than that, but if this works,
I'll do it this way.

Thank you,
mike
-- 
Mike Meyer [EMAIL PROTECTED]  http://www.mired.org/consulting.html
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] 7.4devel auth failed

2003-03-25 Thread Kurt Roeckx
On Tue, Mar 25, 2003 at 12:28:43PM +0100, Andreas Pflug wrote:
 Ok Bruce,
 
 I found out what's happening.
 I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by 
 default. When connecting locally over IP (pgaccess), hba is checked 
 against IPV6 patterns in pg_hba.conf.
 My pgadmin2 machine will connect with an IP4-to-6 mapped address of 
 0::c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to 

You mean :::c0a8:0002 or :::192.168.0.2?
(:::c0a80002 is not valid.)

 dst-in.sin_addr.s_addr=0xc0a80002.

Which is the right value for it.

 On the other side, SockAddr_pton 
 will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ff, and 
 consequently rangeSockAddr will fail.

Something is wrong here.  It somehow converted them to host byte
order where it shouldn't.

SockAddr_pton() basicly does:

return inet_pton(AF_INET, src, sa-in.sin_addr);

Which should return the data in network byte order.

 If your kernel isn't V6 enabled, the incoming socket will be AF_INET, 
 and no conversion is done, that's why you don't get the problem.
 To fix this, the [12]..[15] indices need to be reversed (for Intel). 
 This might be machine specific... Maybe for all big-endian machines the 
 current code is ok, and needs reversal for little-endian processors.
 I wonder if the following is completely portable, could be:
 dst-in.sin_addr.s_addr = *(in_addr_t*)(src-in4.sin6_addr.s6_addr+12);

Where should you place that?

I can't see anything wrong with the code as it is now.  I think I
even tested it for ipv4 and it worked for me, so I have no idea
what's wrong.

I've made alot of changes to the current code but it's not
finnished yet, and really have no time atm.  It currently only
compiles on a host that has ipv6 in libc.  It shouldn't be too
much work to get it to compile on a host without ipv4.


Kurt


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


Re: [HACKERS] Autoheader plan

2003-03-25 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 I want to make pg_config.h.in be automatically generated by autoheader
 so we don't have to edit it by hand, but there is a lot of stuff in
 pg_config.h.in that isn't directly generated by configure, so it needs
 to be moved elsewhere.

Maybe I'm just a Luddite, but I've never understood what autoheader
buys us that's worth the trouble of conforming to its restrictions.
Why should we bother?

(The specifics of your plan are fine if we accept the premise that we
should use autoheader, but I'm not sold on the premise...)

regards, tom lane


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] 7.4devel auth failed

2003-03-25 Thread Kurt Roeckx
On Wed, Mar 26, 2003 at 12:36:00AM +0100, Andreas Pflug wrote:
 Kurt,
 
 for my opinion, ConvSockAddr6to4 works wrong. The resulting ip address 
 looks good for the eye, but only if printed as an integer which will 
 interpret it little-endian (host byte order).

Oops, I didn't see that one.

convSockAddr6to4() is obviously wrong.  There is where it gets
converted to host order where it shouldn't.

What is that SockAddr_ntop() doing there anyway?  Maybe the
inteded code was a combination for SockAddr_ntop() and
SockAddr_pton()?


Kurt


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


[HACKERS] Persistent variables between cross-calls in C functions

2003-03-25 Thread Fabio Furia Silva
Dear all:

I could not find any way to store a value in a C function between calls
inside the same session.

For example, the following function doesn't work as expected:

//
#include postgres.h
#include fmgr.h

PG_FUNCTION_INFO_V1(next_value);

Datum next_value(PG_FUNCTION_ARGS)
{
static int n;
PG_RETURN_INT32(n);
n++;
}

//
create function next_value()
returns integer as
'next.so' language C;

//
Calling

select next_value();

will always return 0,
even if I declare 'n' as a global variable outside the C function.


Thanks a lot.

Fabio Furia Silva


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] [GENERAL] Persistent variables between cross-calls in C functions

2003-03-25 Thread Stephan Szabo

On Tue, 25 Mar 2003, Fabio Furia Silva wrote:

 For example, the following function doesn't work as expected:

 //
 #include postgres.h
 #include fmgr.h

 PG_FUNCTION_INFO_V1(next_value);

 Datum next_value(PG_FUNCTION_ARGS)
 {
 static int n;
 PG_RETURN_INT32(n);
 n++;
 }

 //
 create function next_value()
 returns integer as
 'next.so' language C;

 //
 Calling

 select next_value();

 will always return 0,
 even if I declare 'n' as a global variable outside the C function.

Which seems right since the n++ is never executed (being after the return
statement).  Does it do what you want if you increment first?


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] New structers for optimazing R-tree

2003-03-25 Thread Oleg Bartunov
Anton,

I'd suggest you to start from contrib/rtree_gist. Hacking main source
tree isn't easy task.

Oleg
On Tue, 25 Mar 2003, Anton V. Kozub wrote:

 Good day all.

 My name is Anton Kozub.
 I'm student 5 course of Saint-Petersburg State University, faculty
 mathematics and mechanics, system programming department.

 My science work join with indexing structure R-tree. I have learned many
 papers about R-tree and want realize my ideas, linked(toched) with
 optimizing R-tree, in Your system(PostGreSQL).

 I need Your help for realize my ideas and plans.
 More information about my work i would like to tell to my helper in private
 mail.

 Please mail to [EMAIL PROTECTED] if you want to help me or want to know
 anything about me and my science work.

 Thanks,
 Anton.


 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])