Re: [HACKERS] New version of money type

On Sat, Sep 30, 2006 at 04:42:13AM +, [EMAIL PROTECTED] wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, Sep 29, 2006 at 12:19:07PM +0200, Martijn van Oosterhout wrote: > > On Thu, Sep 28, 2006 at 06:32:11PM -0500, Jim C. Nasby wrote: > If you are at that, it's worth noting

Re: [HACKERS] New version of money type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 29, 2006 at 12:19:07PM +0200, Martijn van Oosterhout wrote: > On Thu, Sep 28, 2006 at 06:32:11PM -0500, Jim C. Nasby wrote: > > What would be ideal is a money type that stored what currency was used > > and let you change precision (within

Re: [HACKERS] Per-database search_path

Added to TODO: * Allow more complex user/database default GUC settings Currently, ALTER USER and ALTER DATABASE support per-user and per-database defaults. Consider adding per-user-and-database defaults so things like search_path can be defaulted fo

Re: [HACKERS] JAVA Support

Henry B. Hotz wrote: > Well, that's why I was pushing SASL instead of GSSAPI. There are > multiple mechanisms that are actually in use. > > PAM turned out not to be sufficiently specified for cross-platform > behavioral compatibility, and it only does password checking anyway. > Calling it

Re: [HACKERS] Win32 hard crash problem

Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> O.k. further on this.. the crashing is happening quickly now but not >> predictably. (as in sometimes a week sometimes 2 days). > > OK, that seems to eliminate the GetTickCount-overflow theory anyway. > >> That log entry is the la

Re: [HACKERS] The enormous s->childXids problem

On Saturday 16 September 2006 20:34, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > Tom Lane <[EMAIL PROTECTED]> writes: > >> The real question is why does the subtransaction actually assign itself > >> an XID --- a simple RETURN NEXT operation ought not do that, AFAICS. > > > > I

Re: [HACKERS] Per-database search_path

David Fetter <[EMAIL PROTECTED]> writes: > On Fri, Sep 29, 2006 at 05:41:35PM -0400, Tom Lane wrote: >> Yeah. ISTM the correct generalization is "per-user per-database >> default GUC settings", which has nothing to do with superuserness. > This sounds like a TODO for 8.3. What wrinkles might thi

Re: [HACKERS] Per-database search_path

On Fri, Sep 29, 2006 at 05:41:35PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Fri, Sep 29, 2006 at 01:06:09PM -0700, Josh Berkus wrote: > >> However, it almost seems like this would become a piece of the > >> other per-database-user stuff we'd like to do, like "local >

Re: [HACKERS] Faster StrNCpy

On Fri, Sep 29, 2006 at 05:34:30PM -0400, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > If anybody is curious, here are my numbers for an AMD X2 3800+: > You did not show your C code, so no one else can reproduce the test on > other hardware. However, it looks like your compiler has unrolled the

Re: [HACKERS] Win32 hard crash problem

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > O.k. further on this.. the crashing is happening quickly now but not > predictably. (as in sometimes a week sometimes 2 days). OK, that seems to eliminate the GetTickCount-overflow theory anyway. > That log entry is the last (of consequence) entry b

Re: [HACKERS] Per-database search_path

David Fetter <[EMAIL PROTECTED]> writes: > On Fri, Sep 29, 2006 at 01:06:09PM -0700, Josh Berkus wrote: >> However, it almost seems like this would become a piece of the other >> per-database-user stuff we'd like to do, like "local superuser". > I'm not sure that's the same. The thing about super

Re: [HACKERS] Faster StrNCpy

[EMAIL PROTECTED] writes: > If anybody is curious, here are my numbers for an AMD X2 3800+: You did not show your C code, so no one else can reproduce the test on other hardware. However, it looks like your compiler has unrolled the memcpy into straight-line 8-byte moves, which makes it pretty ha

Re: [HACKERS] Faster StrNCpy

If anybody is curious, here are my numbers for an AMD X2 3800+: $ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected to be slow."' -o x x.c y.c strlcpy.c ; ./x NONE:620268 us MEMCPY: 683135 us STRNCPY:7952930 us STRLCPY: 10042364 us $ gcc -O3 -std=c99 -D

Re: [HACKERS] Faster StrNCpy

On Fri, Sep 29, 2006 at 11:21:21AM +0200, Markus Schaber wrote: > Tom Lane wrote: > >> Just wondering - are any of these cases where a memcpy() would work > >> just as well? Or are you not sure that the source string is at least > >> 64 bytes in length? > > > > In most cases, we're pretty sure tha

Re: [HACKERS] Per-database search_path

On Fri, Sep 29, 2006 at 01:06:09PM -0700, Josh Berkus wrote: > DF, > > > I'd like to propose a feature for 8.3, which would let login roles > > have a default search_path both globally, as it is now, and > > per-database. This is because in general no two databases have > > any schemas in common,

Re: [HACKERS] Per-database search_path

DF, > I'd like to propose a feature for 8.3, which would let login roles > have a default search_path both globally, as it is now, and > per-database. This is because in general no two databases have > any schemas in common, and a login role should be able to do something > reasonable just by con

[HACKERS] Per-database search_path

Folks, I'd like to propose a feature for 8.3, which would let login roles have a default search_path both globally, as it is now, and per-database. This is because in general no two databases have any schemas in common, and a login role should be able to do something reasonable just by connecting

[HACKERS] Replication hooks discussion

Hello, At the beginning of the month, in , I said that I'd be willing to try to do any sort of co-ordination, document writing, &c. for a project that might define common back-end resources necessary for the various kinds of replic

Re: [HACKERS] [GENERAL] Array assignment behavior (was Re: [ADMIN] Stored procedure

Ok, just so I can be sure I understand what I just read: i. says that you can assign to an array that has not been initialized. ii. states that the index of an insertion into an array should not be limited by the current range of index values of the array and requires any gaps in the index

Re: [HACKERS] [GENERAL] Array assignment behavior (was Re: [ADMIN] Stored procedure array limits)

"John D. Burger" <[EMAIL PROTECTED]> writes: >>> As of 8.2 we could allow assignment to >>> arbitrary positions by filling the intermediate positions with nulls. >>> The code hasn't actually been changed to allow that, but it's >>> something we could consider doing now. >> >> At first blush, thi

Re: [HACKERS] [GENERAL] Array assignment behavior (was Re: [ADMIN] Stored procedure

Yep, that definitely threw me the first time I encountered it. Paul B. Anderson wrote: It seems that the suggestion to fill intermediate positions with NULLs would be preferable to the current behavior. I know of no requirement to populate arrays in sequence in any other language so I think o

Re: [HACKERS] a little doubr about domains and pl/python

"Walter Cruz" <[EMAIL PROTECTED]> writes: > CREATE CAST (integer AS romano) WITH FUNCTION to_roman(integer); > What's wrong? Domains aren't supported as cast source/targets at the moment; I don't think the system is finding your cast specification at all, but is instead doing this as 5::text::rom

Re: [HACKERS] Nulls, arrays, records, IS NULL, IS DISTINCT FROM

David Fetter <[EMAIL PROTECTED]> writes: > On Fri, Sep 29, 2006 at 12:53:19PM -0400, Tom Lane wrote: >> In particular, the spec says >> ROW(1,2,NULL) IS NOT NULL >> is false, because the row fields must be *all* not null to make it true. > That's odd because as I understand the above, > R

Re: [HACKERS] Array assignment behavior (was Re: [ADMIN] Stored procedure array

It seems that the suggestion to fill intermediate positions with NULLs would be preferable to the current behavior.  I know of no requirement to populate arrays in sequence in any other language so I think other programmers would be surprised too by the current behavior. Paul Tom Lane wrot

Re: [HACKERS] Nulls, arrays, records, IS NULL, IS DISTINCT FROM

On Fri, Sep 29, 2006 at 12:53:19PM -0400, Tom Lane wrote: > Following up yesterday's discussion, I've been studying the SQL spec for > and , and it seems a bit > inconsistent. Do you have the official spec in hand, or just the draft from wiscorp? > SQL2003 has completely rewritten the text but t

[HACKERS] Testing strlcpy ()

We've completed some tests comparing Postgres 8.2beta1 (beta1) and Postgres 8.2beta1 with strlcpy () (strlcpy). First and foremost, the patch seems to be stable - we have not run into any issues with it. After a database reload, there is an 11% difference between strlcpy and beta1 - strlcpy

Re: [HACKERS] JAVA Support

On Sep 29, 2006, at 12:31 AM, Magnus Hagander wrote: However, that doesn't change that some people would like us to support GSSAPI, and there may be some benefit (additional applications, better network authentication, etc.) for doing so. If we can get additional programmers to code the

Re: [HACKERS] JAVA Support

On Sep 28, 2006, at 9:35 PM, Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: Is there any reason why we haven't built a generic authentication API? Something like PAM, except cross platform? We're database geeks, not security/crypto/authentication geeks. What makes you think

Re: [HACKERS] Win32 hard crash problem

Joshua D. Drake wrote: > Tom Lane wrote: >> "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >>> Yes, unfortunately there isn't much more to be had for another 2 >>> weeks ;) >> >> I trust they've got the reboot time and they will know exactly how long >> from reboot to problem? I'm not all that sold

[HACKERS] Nulls, arrays, records, IS NULL, IS DISTINCT FROM

Following up yesterday's discussion, I've been studying the SQL spec for and , and it seems a bit inconsistent. The rules for make it clear that you are supposed to "drill down" into row and array values to determine distinctness. SQL99 has a) If the declared type of X or Y is an ar

Re: [HACKERS] Backup and restore through JDBC

Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> Then after you recover from your head exploding you start devising some >> sort of sane API ... >> > > That's the hard part. There is no percentage in having a library if > it doesn't do anything significantly different fro

Re: [HACKERS] [GENERAL] Array assignment behavior (was Re: [ADMIN] Stored procedure array limits)

As of 8.2 we could allow assignment to arbitrary positions by filling the intermediate positions with nulls. The code hasn't actually been changed to allow that, but it's something we could consider doing now. At first blush, this strikes me as a bit too magical/implicit. Are there other la

Re: [HACKERS] [GENERAL] Array assignment behavior (was Re: [ADMIN] Stored procedure array limits)

On Sep 29, 2006, at 9:14 AM, Tom Lane wrote: [ expanding this thread, as it now needs wider discussion ] "Paul B. Anderson" <[EMAIL PROTECTED]> writes: Actually, I was not filling all of the arrays in sequential order. I added code to initialize them in order and the function seems to be work

[HACKERS] a little doubr about domains and pl/python

Hi all. I'm playing with pl/python AND i'm with a doubt. I wanna create a domain to roman numerals. I have made: CREATE OR REPLACE FUNCTION valid_roman(text) RETURNS BOOLEAN IMMUTABLE LANGUAGE plpythonu AS $$ from roman9 import fromRoman roman = args[0] try: r = fromRoman(roman) return 'tr

Re: [HACKERS] Block B-Tree concept

Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: I don't mean consecutive as in "1, 2, 3, 4, ... without gaps" but as in "A and B are consecutive in the index, if there's no value X in the index so that A < X < B". Maybe there's a better word for that. Um, but how are yo

[HACKERS] Array assignment behavior (was Re: [ADMIN] Stored procedure array limits)

[ expanding this thread, as it now needs wider discussion ] "Paul B. Anderson" <[EMAIL PROTECTED]> writes: > Actually, I was not filling all of the arrays in sequential order. I > added code to initialize them in order and the function seems to be > working now. Is that a known problem? Well

Re: [HACKERS] Block B-Tree concept

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> define "consecutive". > I don't mean consecutive as in "1, 2, 3, 4, ... without gaps" but as in > "A and B are consecutive in the index, if there's no value X in the > index so that A < X < B". Maybe there's a better word for th

Re: [HACKERS] Another idea for dealing with cmin/cmax

"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Dumb question... wouldn't getting down to 20 bytes buy us something? Only on 32-bit machines, which are getting less interesting as database servers every day. (Just last night I was reading somebody opining that the transition to 64-bit hardware would

Re: [HACKERS] Backup and restore through JDBC

Andrew Dunstan <[EMAIL PROTECTED]> writes: > Then after you recover from your head exploding you start devising some > sort of sane API ... That's the hard part. There is no percentage in having a library if it doesn't do anything significantly different from what you could accomplish via

Re: [HACKERS] Block B-Tree concept

On Friday 29 September 2006 10:55, Heikki Linnakangas wrote: > Tom Lane wrote: > > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > >> I'm not very interested in the case where you have a lot of equal keys, > >> I think the bitmap index am is more suitable for that. > > > > that indeed you meant to

Re: [HACKERS] Faster StrNCpy

Markus Schaber <[EMAIL PROTECTED]> writes: > There's another disadvantage of always copying 64 bytes: > It may be that the 64-byte range crosses a page boundary. Now guess what > happens when this next page is not mapped -> segfault. Irrelevant, because in all interesting cases the Name field is p

Re: [HACKERS] Block B-Tree concept

Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: I'm not very interested in the case where you have a lot of equal keys, I think the bitmap index am is more suitable for that. that indeed you meant to write "consecutive", and I've got a problem with that: define "consecut

Re: [HACKERS] Block B-Tree concept

On Fri, 2006-09-29 at 14:54 +0100, Heikki Linnakangas wrote: > > The benefit we're seeking with a block index is that most INSERTs don't > > write to the index. With that scheme we'd need to continually update the > > index tuple so that it exactly represented the heap after each inserted > > tupl

Re: [HACKERS] [COMMITTERS] pgsql: Fix IS NULL and IS NOT NULL tests on row-valued expressions to

Teodor Sigaev <[EMAIL PROTECTED]> writes: > 9.17.5. Row-wise Comparison > "These constructs test a row value for null or not null. A row value is > considered not null if it has at least one field that is not null." Wups, I missed that part of the docs, will fix. Thanks.

Re: [HACKERS] Block B-Tree concept

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Imagine a normal B-tree just like what we have now. But when there is > more than one tuple on the same heap page with consecutive index keys, > we represent all of them in a single index tuple that contains the key > of the first one of them, and

Re: [HACKERS] Another idea for dealing with cmin/cmax

On Fri, Sep 29, 2006 at 01:15:06PM +0900, ITAGAKI Takahiro wrote: > > "Jim C. Nasby" <[EMAIL PROTECTED]> wrote: > > > The reason I thought of this is because once the transaction commits, we > > have no use for the cid info. So we could do something like have > > bgwriter look for tuples that bel

Re: [HACKERS] send()/receive() and on-disk storage

Hi, Martijn, Martijn van Oosterhout wrote: > It would be terribly inefficient to call those functions for each > read/write. The disk has the internal format, send/receive deal with a > portable not-host-dependant representation of the data. Thanks. Markus -- Markus Schaber | Logical Tracking

Re: [HACKERS] [COMMITTERS] pgsql: Fix IS NULL and IS NOT NULL tests on row-valued

9.17.5. Row-wise Comparison "These constructs test a row value for null or not null. A row value is considered not null if it has at least one field that is not null." I suppose, it should be changed too. Tom Lane wrote: the SQL spec, viz IS NULL is true if all the row's fields are null, IS N

Re: [HACKERS] Backup and restore through JDBC

Markus Schaber wrote: Marlon Petry wrote: But I would need to have installed pg_dump and pg_restore in machine client? Without having installed pg_dump and pg_restore,how I could make pg_dump and pg_restore should be runnable (possible with a small shell / bash wrapper script) without any "ins

Re: [HACKERS] Block B-Tree concept

Simon Riggs wrote: On Fri, 2006-09-29 at 10:51 +0100, Heikki Linnakangas wrote: Heikki Linnakangas wrote: If we want to keep the property that VACUUM doesn't re-evaluate index entries, any proposal that doesn't keep track of every heap tuple isn't going to work. I'll try to modify the design I

Re: [HACKERS] send()/receive() and on-disk storage

On Fri, Sep 29, 2006 at 03:44:07PM +0200, Markus Schaber wrote: > Does PostgreSQL call the datatypes' defined send() function before > storing the tuple data in the table, on disk, and call receive() when > reading it again? No. > My position was that send()/receive() are only used for client > c

[HACKERS] send()/receive() and on-disk storage

Hi, Currently, there's a discussion on the pljava list, and we're confused about a small detail: Does PostgreSQL call the datatypes' defined send() function before storing the tuple data in the table, on disk, and call receive() when reading it again? My position was that send()/receive() are on

Re: [HACKERS] Backup and restore through JDBC

Marlon Petry wrote:>>> > You can't. pg_dump in particular embodies an enormous amount of > > knowledge that simply does not exist elsewhere. There is no> > dump/restore API, and there is nothing you can hook up to using JNI,> > AFAIK.> Recently, there was the proposal to extract

Re: [HACKERS] Backup and restore through JDBC

Marlon Petry wrote:> > You can't. pg_dump in particular embodies an enormous amount of > knowledge that simply does not exist elsewhere. There is no > dump/restore API, and there is nothing you can hook up to using JNI, > AFAIK. Recently, there was the proposal to extract tha

Re: [HACKERS] Block B-Tree concept

Csaba Nagy <[EMAIL PROTECTED]> writes: > > > I think you build a whole new index named something like ".temp-reindex" > > > and > > > then as the last step of the second transaction delete the old idnex and > > > rename the new index. > > > > That would require getting exclusive lock on the tabl

Re: [HACKERS] Backup and restore through JDBC

> Marlon Petry wrote: >> pg_dump and pg_restore do not need to run on the server machine.>> Why not>> just run them where you want the dump stored?>> But I would need to have installed pg_dump and pg_restore in machine >> client?>> Without having installed pg_dump and pg_res

Re: [HACKERS] Backup and restore through JDBC

Hi, Marlon, Marlon Petry wrote: > But I would need to have installed pg_dump and pg_restore in machine > client? > Without having installed pg_dump and pg_restore,how I could make pg_dump and pg_restore should be runnable (possible with a small shell / bash wrapper script) without any "installat

Re: [HACKERS] Backup and restore through JDBC

Andrew Dunstan wrote: > Marlon Petry wrote: >> >> >> pg_dump and pg_restore do not need to run on the server machine. >> Why not >> just run them where you want the dump stored? >> >> >> >> >> But I would need to have installed pg_dump and pg_restore in machine >> client? >> Without hav

Re: [HACKERS] Block B-Tree concept

On Fri, 2006-09-29 at 10:51 +0100, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: > > If we want to keep the property that VACUUM doesn't re-evaluate index > > entries, any proposal that doesn't keep track of every heap tuple > > isn't going to work. I'll try to modify the design I had in

Re: [HACKERS] Backup and restore through JDBC

Marlon Petry wrote: pg_dump and pg_restore do not need to run on the server machine. Why not just run them where you want the dump stored? But I would need to have installed pg_dump and pg_restore in machine client? Without having installed pg_dump and pg_restore,how I could m

Re: [HACKERS] Backup and restore through JDBC

>> The idea is to make one pg_dump of the server and to keep in the > machine of client.> And to restore this pg_dump when it will be necessary through the> machine of the client.> Perhaps I will have that to use some store procedure in the server, I> do not know >>pg_dump and pg_restore do not nee

Re: [HACKERS] Backup and restore through JDBC

Marlon Petry wrote: The idea is to make one pg_dump of the server and to keep in the machine of client. And to restore this pg_dump when it will be necessary through the machine of the client. Perhaps I will have that to use some store procedure in the server, I do not know pg_dump and p

Re: [HACKERS] Backup and restore through JDBC

The idea is to make one pg_dump of the server and to keep in the machine of client.And to restore this pg_dump when it will be necessary through the machine of the client.Perhaps I will have that to use some store procedure in the server, I do not know regardsMarlon2006/9/29, Albe Laurenz < [EMAI

Re: [HACKERS] Block B-Tree concept

Martijn van Oosterhout wrote: On Fri, Sep 29, 2006 at 10:51:32AM +0100, Heikki Linnakangas wrote: After some thought: Imagine a normal B-tree just like what we have now. But when there is more than one tuple on the same heap page with consecutive index keys, we represent all of them in a single

Re: [HACKERS] New version of money type

On Thu, Sep 28, 2006 at 06:32:11PM -0500, Jim C. Nasby wrote: > What would be ideal is a money type that stored what currency was used > and let you change precision (within reason). The taggedtypes version of currency does half of that, by storing the currency and allowing the output format to de

Re: [HACKERS] Block B-Tree concept

On Fri, Sep 29, 2006 at 10:51:32AM +0100, Heikki Linnakangas wrote: > After some thought: > > Imagine a normal B-tree just like what we have now. But when there is > more than one tuple on the same heap page with consecutive index keys, > we represent all of them in a single index tuple that con

Re: [HACKERS] Another idea for dealing with cmin/cmax

Martijn van Oosterhout wrote: On Fri, Sep 29, 2006 at 10:59:13AM +0100, Heikki Linnakangas wrote: Martijn van Oosterhout wrote: On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote: We could get rid of t_hoff, because we should always be able to calculate the header size. Then we

Re: [HACKERS] Another idea for dealing with cmin/cmax

On Fri, Sep 29, 2006 at 10:59:13AM +0100, Heikki Linnakangas wrote: > Martijn van Oosterhout wrote: > >On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote: > >>We could get rid of t_hoff, because we should always be able to > >>calculate the header size. Then we're down to 18 bytes.

Re: [HACKERS] Another idea for dealing with cmin/cmax

Martijn van Oosterhout wrote: On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote: We could get rid of t_hoff, because we should always be able to calculate the header size. Then we're down to 18 bytes. Without t_hoff, how do you know the size of the null bitmap? You could proba

Re: [HACKERS] Another idea for dealing with cmin/cmax

On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote: > We could get rid of t_hoff, because we should always be able to > calculate the header size. Then we're down to 18 bytes. Without t_hoff, how do you know the size of the null bitmap? You could probably do it only if you assume

Re: [HACKERS] Block B-Tree concept

Heikki Linnakangas wrote: If we want to keep the property that VACUUM doesn't re-evaluate index entries, any proposal that doesn't keep track of every heap tuple isn't going to work. I'll try to modify the design I had in mind so that it does keep track of every heap tuple in some form. After

Re: [HACKERS] Faster StrNCpy

Hi, Tom, Tom Lane wrote: > "Strong, David" <[EMAIL PROTECTED]> writes: >> Just wondering - are any of these cases where a memcpy() would work >> just as well? Or are you not sure that the source string is at least >> 64 bytes in length? > > In most cases, we're pretty sure that it's *not* --- it'

Re: [HACKERS] Another idea for dealing with cmin/cmax

ITAGAKI Takahiro wrote: However, I think our next goal to shrink the headers is 16 bytes. The headers become 23 bytes using phantom cids and we are limited by alignments, so we will have no more advantages unless we delete extra 7 bytes in the headers. ...and it seems to be very difficult. Ye

Re: [HACKERS] JAVA Support

This being SASL: > > I know I tried to make > > it work on win32 once and failed miserably. (Then again, I've > failed > > on Linux as well, but not quite as bad. And it's not included in > all > > Linux distributions, at least it wasn't when I checked a while > back) > > Well, I know Redhat has

Re: [HACKERS] JAVA Support

> > However, that doesn't change that some people would like us to > support > > GSSAPI, and there may be some benefit (additional applications, > better > > network authentication, etc.) for doing so. If we can get > additional > > programmers to code the support (i.e. Sun, JPL) I don't see any >

Re: [HACKERS] JAVA Support

> > I would if we could get some -hackers buy in on the idea. Adding > more > > and more auth methods is something they're not excited about > unless > > there's a good reason (which I think this is). > > Actually, I've been trying to get some of the Sun engineers to > contribute patches for Sola

Re: [HACKERS] Backup and restore through JDBC

Marlon Petry wrote: > I am trying to develop, a API to carry through backup and > restore through JDBC. > I think that the best form is to use JNI. > Some Suggestion? Do you mean 'backup' or 'export/dump'? If you mean 'export', do you need anything besides SQL? If you mean 'backup', how do you