Re: [HACKERS] CREATE OR REPLACE VIEW/TRIGGER

2001-10-27 Thread Rene Pijlman

On Tue, 23 Oct 2001 17:16:06 +0200, you wrote:
CREATE OR DROP VIEW 

Is this for real? If I were a database server I would say to the
client please make up your mind :-)

Regards,
René Pijlman [EMAIL PROTECTED]

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



Re: [HACKERS] anoncvs and CVS link off developers.postgresql.org

2001-10-06 Thread Rene Pijlman

On Sat, 6 Oct 2001 14:14:23 -0500, you wrote:
If I try:
cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login 
I get a time out

Same here an hour ago, but it seems to be fixed now.

Regards,
René Pijlman [EMAIL PROTECTED]

---(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] querying system catalogs to extract foreign keys

2001-09-14 Thread Rene Pijlman

On 13 Sep 2001 22:56:16 -0700, you wrote:
I tried to use the getImportedKeys and getExportedKeys of 
java.sql.DatabaseMetadata... But it didnt give any expected 
results... 

This is probably a limitation or bug in the JDBC driver. Please
post details of your problem on [EMAIL PROTECTED] E.g.
what results did you get, and what did you not get?

So can anyone tell me how to query the system
catalogs to extract this info??

The system catalogs are documented on
http://www.postgresql.org/idocs/index.php?catalogs.html

Regards,
René Pijlman [EMAIL PROTECTED]

---(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] Timezones and time/timestamp values in FE/BE protocol

2001-09-09 Thread Rene Pijlman

I'm working on a problem in the JDBC driver that's related to
timezones.

How does PostgreSQL handle timezones in the FE/BE protocol
exactly?

When a client sends a time or timestamp value to the server via
the FE/BE protocol, should that be:
1) a value in the client's timezone?
2) a value in the server's timezone?
3) a value in a common frame of reference (GMT/UTC)?
4) any value with an explicit timezone?

And how should a time or timestamp value returned by the server
be interpreted in the client interface?

And how does this all depend on the timezone setting of the
server?

Regards,
René Pijlman [EMAIL PROTECTED]

---(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] [JDBC] NULLs and sort order

2001-09-09 Thread Rene Pijlman

On Sun, 9 Sep 2001 15:25:17 +0200 (CEST), you wrote:
That is correct.

Thanks.

 Would it be useful to add this information to the documentation,
 e.g. the documentation of ORDER BY in SELECT?

Most likely.

I'll post it on the docs list.

Regards,
René Pijlman [EMAIL PROTECTED]

---(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] [JDBC] Troubles using German Umlauts with JDBC

2001-09-04 Thread Rene Pijlman

[forwarding to pgsql-hackers and Bruce as Todo list maintainer,
see comment below]

[insert with JDBC converts Latin-1 umlaut to ?]
On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote:
You have to set the encoding when you make the connection.

Properties props = new Properties();
props.put(user,user);
props.put(password,password);
props.put(charSet,encoding);
Connection con = DriverManager.getConnection(url,props);
where encoding is the proper encoding for your database

For completeness, I quote the answer Barry Lind gave yesterday. 

[the driver] asks the server what character set is being used
for the database.  Unfortunatly the server only knows about
character sets if multibyte support is compiled in. If the
server is compiled without multibyte, then it always reports to
the client that the character set is SQL_ASCII (where SQL_ASCII
is 7bit ascii).  Thus if you don't have multibyte enabled on the
server you can't support 8bit characters through the jdbc
driver, unless you specifically tell the connection what
character set to use (i.e. override the default obtained from
the server).

This really is confusing and I think PostgreSQL should be able
to support single byte encoding conversions without enabling
multi-byte. 

To the very least there should be a --enable-encoding-conversion
or something similar, even if it just enables the current
multibyte support.

Bruce, can this be put on the TODO list one way or the other?
This problem has appeared 4 times in two months or so on the
JDBC list.

Regards,
René Pijlman [EMAIL PROTECTED]

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl



[HACKERS] Multiple semicolon separated statements and autocommit

2001-08-30 Thread Rene Pijlman

We're discussing an implementation of JDBC's
Statement.executeBatch() on the pgsql-jdbc list. The idea is to
send multiple semicolon separated statements in one call to the
backend. The purpose of this feature is of course a performance
improvement, since it executes multiple (non-select) statements
with one round trip to the server.

If autocommit is _enabled_ and S1;S2;S3 is send to the database,
what exactly is the behaviour of the backend? For example, what
happens if S1 succeeds, S2 fails and S3 would succeed?

Does autocommit apply to the statement list send in one call as
a whole? Or does it apply to individual statements?

If autocommit applies to the list as a whole I assume the
failure of S2 would cause the entire statement list to fail and
be rolled back.

If autocommit applies to individual statements in the list, I
assume that S1 succeeds and is committed, S2 fails and is rolled
back. But is S3 still executed? And what update count is
returned to the client in that case?

I will summarize on pgsql-jdbc.

Regards,
René Pijlman [EMAIL PROTECTED]

---(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] Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...]

2001-08-23 Thread Rene Pijlman

On Thu, 23 Aug 2001 14:44:19 -0400, you wrote:
Ned Wolpert [EMAIL PROTECTED] writes:
 Should the backend support the function getLastInsertedOID()?

seems doable and reasonable to me: whenever an OID is returned
to the client in an INSERT or UPDATE command result, also stash it in
a static variable that can be picked up by this function.

What should the semantics be exactly?

How about the multiple INSERT's i've been reading about on
hackers? ... Only the OID of the last row inserted by the
statement?

How about an UPDATE statement that updates multiple rows?

How about JDBC batchExecute() when it performs multiple
INSERT/UPDATE's? ... Only the OID of the last UPDATE or INSERT
statement in the batch?

How about triggers that insert/update extra rows? ... Only the
OID of the row directly inserted by the client statement?

How about Large Objects? Should inserting or updating a large
object affect getLastInsertedOID()?

I assume this OID would be associated with a client connection.
Is this going to work with client side connection pooling?

How about transaction semantics? INSERT row 1, Commit, INSERT
row 2, Rollback... what should getLastInsertedOID() return? Can
it, with a static variable?

Regards,
René Pijlman

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl



[HACKERS] Re: Vim!

2001-08-06 Thread Rene Pijlman

Grant wrote:
Is it at all possible to use vim to interact with psql to 
provide input?

Why are you asking this on hackers? Please read
http://www.postgresql.org/devel-corner/ (YOU MUST TRY ELSEWHERE
FIRST)

Yes, psql can call vim. Its in the user documentation. You may
want to read that too.

Regards,
René Pijlman

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