Re: [HACKERS] CREATE CAST code review
Tom wrote: Peter Eisentraut [EMAIL PROTECTED] writes: That doesn't quite work, because then no ordinary user can define a cast from some built-in type to his own type. What I'm thinking about is to implement the USAGE privilege on types, and then you need to have that to be allowed to create casts. Still seems too weak. Yes. What about requiring ownership of at least one of the types? I was thinking that too, but, would it be possible to circumvent such a restriction with a type in the middle attack ? Create your own type and then 1. (auto)cast type1 to own type 2. (auto)cast own type to type2 ? Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Access Two Databases
On Tuesday 23 July 2002 02:59, Joe Conway wrote: Darren Ferguson wrote: Not that i am aware of On Tue, 23 Jul 2002, Dean Grubb wrote: Hi, Is it possible using pl/pgSQL functions to grab data from another database or even another database on a different host. You can with contrib/dblink. Hi Joe ! Remember me ? Before about 3 months I send to You pl/pgSql wrapper functions for libpq. We agreed then, that merging it with dblink would be a good idea. Meanwhile i used dblink and those functions and wrote some kind of replication for my app. Is there interest for such interface, or should I forget the whole thing ? regards ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] RAMDISK
I've finally got around to try RAMDISK with PostgreSQL. The attached doccontains the test results that I'd like to share with PostgreSQL's usersanddevelopers groups. Regards,Samuel Sutjiono_Expand your wireless world with Arkdom PLUShttp://www.arkdom.com/ RAMDISK POC Result.xls Description: MS-Excel spreadsheet ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RAMDISK
Interesting results. You didn't really offer much in how your system was configured to use the ramdisk. Did you use it to simply store a database on it? Was the entire database able to fit into available memory even without the RAMDISK? Did you try only storing indicies on the RAMDISK? There are lots of other questions that unanswered on the topic. Worth mentioning that it is very possible and in fact, fairly easy to do, for the use of a RAMDISK to significantly hinder the performance of a system running a database. Greg On Tue, 2002-07-23 at 09:36, Samuel J. Sutjiono wrote: I've finally got around to try RAMDISK with PostgreSQL. The attached doc contains the test results that I'd like to share with PostgreSQL's users and developers groups. Regards, Samuel Sutjiono _ Expand your wireless world with Arkdom PLUS http://www.arkdom.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [PATCHES] prepareable statements
[EMAIL PROTECTED] (Neil Conway) writes:
Regarding the syntax for EXECUTE, it occurs to me that it could be made
to be more similar to the PREPARE syntax -- i.e.
PREPARE foo(text, int) AS ...;
EXECUTE foo('a', 1);
(rather than EXECUTE USING -- the effect being that prepared statements
now look more like function calls on a syntactical level, which I think
is okay.)
Hmm, maybe *too* much like a function call. Is there any risk of a
conflict with syntax that we might want to use to invoke stored
procedures? If not, this is fine with me.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Demo patch for DROP COLUMN
Christopher Kings-Lynne [EMAIL PROTECTED] writes: But you *didn't* make sure it would never be a problem. Wasn't I looping until I found a unique name? My point was that there could still be a conflict against a user column that the user tries to create *later*. So it's illusory to think that making the name of a dropped column less predictable will improve matters. regards, tom lane ---(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] [PATCHES] prepareable statements
On Tue, 2002-07-23 at 11:34, Tom Lane wrote:
[EMAIL PROTECTED] (Neil Conway) writes:
Regarding the syntax for EXECUTE, it occurs to me that it could be made
to be more similar to the PREPARE syntax -- i.e.
PREPARE foo(text, int) AS ...;
EXECUTE foo('a', 1);
(rather than EXECUTE USING -- the effect being that prepared statements
now look more like function calls on a syntactical level, which I think
is okay.)
Hmm, maybe *too* much like a function call. Is there any risk of a
conflict with syntax that we might want to use to invoke stored
procedures? If not, this is fine with me.
Stored procedures would use PERFORM would they not?
I like the function syntax. It looks and acts like a temporary 'sql'
function.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PATCHES] prepareable statements
Rod Taylor wrote:
On Tue, 2002-07-23 at 11:34, Tom Lane wrote:
[EMAIL PROTECTED] (Neil Conway) writes:
Regarding the syntax for EXECUTE, it occurs to me that it could be made
to be more similar to the PREPARE syntax -- i.e.
PREPARE foo(text, int) AS ...;
EXECUTE foo('a', 1);
(rather than EXECUTE USING -- the effect being that prepared statements
now look more like function calls on a syntactical level, which I think
is okay.)
Hmm, maybe *too* much like a function call. Is there any risk of a
conflict with syntax that we might want to use to invoke stored
procedures? If not, this is fine with me.
Stored procedures would use PERFORM would they not?
I like the function syntax. It looks and acts like a temporary 'sql'
function.
FWIW, Oracle uses EXECUTE to execute stored procedures. It is not apart
of the SQL language, but a SQL*Plus command:
EXECUTE my_procedure();
The Oracle call interface defines a function to call stored procedures:
OCIStmtExecute();
Likewise, the privilege necessary to execute a stored procedure is
'EXECUTE' as in:
GRANT EXECUTE ON my_procedure TO mascarm;
Again, FWIW.
Mike Mascari
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Howmany connections postgres can handle upto?
Hi, We are moving to postgres from Oarcle. When we were with Oracle, we were using a total of 160 connections(4 app servers each maintaining a pool of 40 connections). After moving to postgres we want to make it higher i.e make it 60 connections for each app server i.e a total of 240 connections. How will postgres behave with this many no of connections? Thanks Yuva Sr. Java Developer www.ebates.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Howmany connections postgres can handle upto?
On Tue, Jul 23, 2002 at 01:01:42PM -0700, Yuva Chandolu wrote: Hi, We are moving to postgres from Oarcle. When we were with Oracle, we were using a total of 160 connections(4 app servers each maintaining a pool of 40 connections). After moving to postgres we want to make it higher i.e make it 60 connections for each app server i.e a total of 240 connections. How will postgres behave with this many no of connections? It rather depends. For instance, are you running on a 386 with 4 megs of memory? I expect that it won't work. If you are running on an 8-way Sun box with 16 gig of memory, I can report that you can have 1024 connections without undue pain. A -- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M6K 3E3 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pgaccess 0.98.8 - weekly release 1
Hello, pgaccess 0.98.8 weekly release 1 is available for download from the pgaccess web site - www.pgaccess.org This version is the net effect of the effort started about April this year for merging three large groups of patches accumulated by Bartus, Boyan and Chris. Since then the pgaccess development group enlarged with the efforts of even more people - http://www.pgaccess.org/?page=12 The pgaccess 0.98.8 is planned to be released together with PostgreSQL 7.3 Bug reports and ideas are welcome. All best, Iavor -- www.pgaccess.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Demo patch for DROP COLUMN
On Tue, 2002-07-23 at 20:42, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: But you *didn't* make sure it would never be a problem. Wasn't I looping until I found a unique name? My point was that there could still be a conflict against a user column that the user tries to create *later*. So it's illusory to think that making the name of a dropped column less predictable will improve matters. The simple (to describe, perhaps not to implement ;) way to resolve it would be for the ADD COLUMN (or CREATE TABLE INHERITS) rename the offending deleted column once more. -- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PITR and rollback
Any chance you can work on save points/nested transactions? See doc/TODO.detail/transactions for info. I can help explaining the ideas in there. --- Dhruv Pilania wrote: Hi, I am a new postgresql developer. needed some help with wal/PITR. Can someone working in this area answer my question? (the email looks long but the question is simple :) ) I have been trying to implement undo of transactions using wal. i.e. given a xid x, postgres can undo all operations of x. For starters, I want to do this in very simple cases i.e. assume x only inserts/updates/deletes tuples and does not change database schema. also I assume that all of x's wal entries are in one segment. The code for this is quite simple if database supports undo or rollback to a point in time. There is a lot of discussion on the mailing list about PITR. I am eagerly waiting for the PITR code to be available on cvs. so my questions are 1. once PITR has been implemented, infinite play forward will work. Will undo also be supported? i.e. can we recover to the past from a current wal log? as a very simple scenario--- xid 1 insert record y in relation r commit xid 2 update record x in relation r commit shutdown ---now we take database back to start of xid 1. if answer to qn 1 is no... 2. my approach is something like this, scan log back until start of transaction record scan forward until commit record if record is for transaction x undo(record) to undo, use preimage in record and everything else is pretty much same as redo. i.e. we open relation, get desired block and work on it etc. can someone tell me if this will work? hoping someone currently working on wal/pitr can help me on this issues thanks, Dhruv PS. transaction dependency tracking --- I added support in postgres to do transaction dependency tracking. basically, x depends on y if x reads something written by y. I maintain a dependency graph and also a corresponding disk based log that is accessed only at transaction commit. there is a tool which can be used to query this graph. the time over heads are pretty low ( 1%). with a dependency graph a DBA can say I want to undo transaction x and all transactions that depend on x. so now in the second phase, I am looking at undo of a transactions. any thoughts on this are very welcome -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] contrib/ltree for 7.2 or 7.3 ?
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Oleg Bartunov wrote: On Sun, 21 Jul 2002, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: We are about to submit brand bew contrib/ltree module (first draft of documetation is available from http://www.sai.msu.su/~megera/postgres/gist/ltree/) and I have a question what version to submit - 7.2 or 7.3 ? 7.3. There are unlikely to be any more 7.2 releases, and in any case they would be bugfixes only, no new features. OK. We've got documentation written and the module could be downloaded from http://www.sai.msu.su/~megera/postgres/gist/ltree/ltree.tar.gz It's works with current CVS and there is patch.72 within the archive, so people could use it with 7.2 release. I've attached text version of documentation, it's about 16Kb, sorry for that. HTML version is available from http://www.sai.msu.su/~megera/postgres/gist/ltree/ Also, we prepared test data based on DMOZ catalog (about 300,000 nodes) and encourage people to play with queries. One known issue: It'll not works with 64-bit OS. We'll certainly fix this but will appreciate if somebody with access to 64-bit machine could help us. It's known problem with byte-alignment. regards, tom lane 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 Content-Description: [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] C vs. C++ contributions
Tom Lane wrote: Marc Lavergne [EMAIL PROTECTED] writes: never any mention of C++ (libpq++ excepted). So, at a risk of stating the obvious (and I'm 99.99% sure I am), does backend code need to be submitted as C even if it's for an entirely NEW module? Backend code must be C; we do not want to deal with C++ portability issues. Is it something that could be in /conrib? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] prepareable statements
Mike Mascari wrote:
FWIW, Oracle uses EXECUTE to execute stored procedures. It is not apart
of the SQL language, but a SQL*Plus command:
EXECUTE my_procedure();
Also with Transact SQL (i.e. MSSQL and Sybase)
Syntax
Execute a stored procedure:
[[EXEC[UTE]]
{
[@return_status =]
{procedure_name [;number] | procedure_name_var
}
[[@parameter =] {value | variable [OUTPUT] | [DEFAULT]]
[,...n]
[WITH RECOMPILE]
However, as Peter E. has pointed out, SQL99 uses the keyword CALL:
15.1 call statement
Function
Invoke an SQL-invoked routine.
Format
call statement ::= CALL routine invocation
FWIW,
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Access Two Databases
Darko Prenosil wrote: Before about 3 months I send to You pl/pgSql wrapper functions for libpq. We agreed then, that merging it with dblink would be a good idea. Meanwhile i used dblink and those functions and wrote some kind of replication for my app. Is there interest for such interface, or should I forget the whole thing ? I still think it might be a good idea -- I just haven't had time to work on dblink recently. I have a few things on my personal TODO list ahead of it yet. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Demo patch for DROP COLUMN
My point was that there could still be a conflict against a user column that the user tries to create *later*. So it's illusory to think that making the name of a dropped column less predictable will improve matters. The simple (to describe, perhaps not to implement ;) way to resolve it would be for the ADD COLUMN (or CREATE TABLE INHERITS) rename the offending deleted column once more. Hah! What a wonderful idea! Now why didn't I think of that! Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] partial index on system indexes?
Tatsuo Ishii wrote: It seems bootstrap parser(bootparse.y) does not accept partial index definitions. Is there any reason for this? Probably just because we never needed them. We could add it, or just create the index later in the initdb script. That later seems easier. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] partial index on system indexes?
Tatsuo Ishii wrote: It seems bootstrap parser(bootparse.y) does not accept partial index definitions. Is there any reason for this? In private email with Tatsuo, I learned it is for the new loadable encoding patch, and he wants to use the index from the syscache. The reason for the partial index is because the index itself would not be unique, but a partial index would be unique. Because the index is part of the syscache, we have to create it as part of initdb bootstrap, rather than in the initdb script. Tatsuo mentioned there is a boolean, and he only wants cases where the boolean is true, and such values are unique. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PATCHES] prepareable statements
To expand on the Oracle implementation, the EXECUTE command in SQL*Plus
results in an anonymous pl/sql block (as opposed to a named procedure).
being sent over the wire such as the following:
begin
my_procedure();
end;
As mentioned in the previous post, the EXECUTE command is only a
SQL*Plus keyword (well, Server Manager too but that was killed in 9i).
Mike Mascari wrote:
Rod Taylor wrote:
On Tue, 2002-07-23 at 11:34, Tom Lane wrote:
[EMAIL PROTECTED] (Neil Conway) writes:
Regarding the syntax for EXECUTE, it occurs to me that it could be made
to be more similar to the PREPARE syntax -- i.e.
PREPARE foo(text, int) AS ...;
EXECUTE foo('a', 1);
(rather than EXECUTE USING -- the effect being that prepared statements
now look more like function calls on a syntactical level, which I think
is okay.)
Hmm, maybe *too* much like a function call. Is there any risk of a
conflict with syntax that we might want to use to invoke stored
procedures? If not, this is fine with me.
Stored procedures would use PERFORM would they not?
I like the function syntax. It looks and acts like a temporary 'sql'
function.
FWIW, Oracle uses EXECUTE to execute stored procedures. It is not apart
of the SQL language, but a SQL*Plus command:
EXECUTE my_procedure();
The Oracle call interface defines a function to call stored procedures:
OCIStmtExecute();
Likewise, the privilege necessary to execute a stored procedure is
'EXECUTE' as in:
GRANT EXECUTE ON my_procedure TO mascarm;
Again, FWIW.
Mike Mascari
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
