Re: [SQL] need to join successive log entries into one

2001-03-15 Thread Richard Huxton
George Young wrote: > > On Wed, 14 Mar 2001, you wrote: > > On 3/14/01, 5:24:12 PM, George Young <[EMAIL PROTECTED]> wrote regarding [SQL] > > I need to join successive log entries into one: > > > I have a table like: > > > > > run | seq | start| done > > > 1415|261| 200

[SQL] Some questions about PLpgSql

2001-03-15 Thread datactrl
Hi, all By using 'PLpgsql', is that possible to 1) check if a specific table exists? 2) check if an INSERT/UPDATE/ DELETE has done successfully? Is there some more documents or samples for PLpgsql except USER GUIDE and PostgreSQL Introduction & concept? THANK YOU JACK ---

[SQL] How to cast text to cidr/inet

2001-03-15 Thread Sondaar Roelof
Hello, I am battleling around to get a text field into a cidr and inet type field. The documentation says things like CAST(val AS text) but inet and cidr does not seem to exist. However the following works: dhcp=# insert into dhcp_subnet(ipaddress) values('139.122.172/18'); INSERT 46172 1 dhcp=#

[SQL] Help with UPDATE syntax

2001-03-15 Thread Jeff Putsch
Howdy, I am porting a bit of code from ORACLE to PostgreSQL 7.1 and am getting stuck on an update statment. I am NOT a SQL expert, merely a beginner swimming hard, so any help will be greatly appreciated. The specific query looks like this: begin transaction update user_group

RE: [SQL] Some questions about PLpgSql

2001-03-15 Thread Sondaar Roelof
Hello jack, To check if a table exists you could use: select tablename from pg_tables; For instance: dhcp=# select count(*) from pg_tables where tablename='dhcp_subnet'; count --- 1 (1 row) dhcp=# select count(*) from pg_tables where tablename='dhcp_subnetaa'; count --- 0 (1

Re: [SQL] Help with UPDATE syntax

2001-03-15 Thread Tom Lane
Jeff Putsch <[EMAIL PROTECTED]> writes: > update > user_group_map map Postgres doesn't allow UPDATE to use an alias for the target table (SQL92 doesn't either). Get rid of the alias name "map", and write the full table name "user_group_map" in the places where "map" is used in th

[SQL] RE: Help with UPDATE syntax

2001-03-15 Thread Michael Davis
Try eliminating the statement " from user_group_map map". It does not belong in the update. Here is the fully rewritten statement: update user_group_map set user_id = 4 where user_id = 9 and not exists ( select * from

Re: [SQL] PL/PgSQL and NULL

2001-03-15 Thread Jan Wieck
Jie Liang wrote: > > I think that is a bug in plpgsql, > when passing a NULL into a plpgsql defined function, it treats > other arguments as NULL also, you can use raise notice in > your function to watch this buggy thing(see following). You're blaming the wrong code for it. It's an insuffi

Re: [SQL] Some questions about PLpgSql

2001-03-15 Thread Josh Berkus
Jack, > 2) check if an INSERT/UPDATE/ DELETE has done successfully? This happens automatically, within a PL/pgSQL function. If the INSERT/UPDATE errors out, the function automatically halts. Actually, this kind of behaviour can be annoying the other way (sometimes one doesn't care about the er

Re: [SQL] List Concatination

2001-03-15 Thread Josh Berkus
Richard, I wanted to thank you for the concatination suggestion ... on testing, a custom aggregate *was* faster than procedural concatination ... much faster. > But - if you don't care about the order of contacts you can define an > aggregate function: > > create aggregate catenate(sfun

Re: [SQL] Some questions about PLpgSql

2001-03-15 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > Now, testing how many rows were inserted/updated/deleted ... that I'm > not sure about. It would be nice to have a ROWS_AFFECTED returned from > a data manipulation query in PL/pgSQL, but I don't believe that that has > been implemented. It has as of 7.1

Re: [SQL] List Concatination

2001-03-15 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: >> Note that this is probably not a good idea - the ordering of the >> contacts will not be well-defined. When I asked about this Tom Lane was >> quite surprised that it worked, so no guarantees about long-term >> suitability. > Hmmm ... this feature is ver

[SQL] VACUUM kills Index Scans ?!

2001-03-15 Thread Gerald Gutierrez
I'm confused over two question involving PostgreSQL index scans. I'm using Linux Mandrake 7.2 on Intel, and PostgreSQL 7.0.3. If someone can explain what's going on, I'd greatly appreciate it. - 1) When I create a empty table, and then immediate cre

Re: [SQL] VACUUM kills Index Scans ?!

2001-03-15 Thread Gerald Gutierrez
As additional information that I neglected to include in the first message, after both tests, the indices clearly still exist and can be seed in the following commands: \d t1 \d t2 \di \d t1_a_ndx \d t2_a_ndx The output shows what's expected, e.g: test1=> \di List of relations Name | Type |

[SQL] Re: Normalization is always good?

2001-03-15 Thread Josh Berkus
Jamu, > I have been working with SQL databases for about a year in a half and > in that time I've come to the conclusion that it is not always > preferable to normalize to a high level (like 3rd level). In some > cases, depending on the application, I've found that normalizing to a > ridiculous

Re: [SQL] VACUUM kills Index Scans ?!

2001-03-15 Thread Tom Lane
Gerald Gutierrez <[EMAIL PROTECTED]> writes: > 1) When I create a empty table, and then immediate create an index on a > column, I can get /index scans/ when searching on that column. But when I > then run VACUUM, the same search becomes a /sequential scan/. VACUUM updates the planner's statist

Re: [SQL] VACUUM kills Index Scans ?!

2001-03-15 Thread Stephan Szabo
On Thu, 15 Mar 2001, Gerald Gutierrez wrote: > 1) When I create a empty table, and then immediate create an index on a > column, I can get /index scans/ when searching on that column. But when I > then run VACUUM, the same search becomes a /sequential scan/. Shouldn't it > still be an index s

Re: [SQL] VACUUM kills Index Scans ?!

2001-03-15 Thread Gerald Gutierrez
>There is an undocumented little factoid here: CREATE INDEX will update >(some of) the planner stats, but only if it finds some data in the >table. CREATE INDEX on an empty table leaves the initial default >numbers alone. This may be contributing to your confusion, but it was >deemed necessary

Re: [SQL] PL/pgSQL "compilation error"

2001-03-15 Thread Jan Wieck
Josh Berkus wrote: > This brings up an important point. We have a medium-large user base for > PL/pgSQL out there, but it appears that Jan Wieck no longer has time to > develop the language ... nor should he be the sole developer. Howe do > we find more developers to expand & extend PL/pgSQL? I

Re: [SQL] pl/Perl

2001-03-15 Thread Jan Wieck
Jie Liang wrote: > Tom, > > 1.Where or how I can get pltcl.so? I have not find this file anywhere in > my > source except a pltcl.c. > 2.Dose installation same as plpgsql? > i.e. > CREATE FUNCTION pltcl_call_handler () RETURNS OPAQUE AS > '/usr/local/pgsql/lib/pltcl.so' LANGUAGE 'C'; > C

Re: [SQL] FETCH ... INTO in PL/pgSQL

2001-03-15 Thread Jan Wieck
Josh Berkus wrote: > Tom, Bruce, > >Is there any way to make use of the contents of a cursor in a PL/pgSQL > function? FETCH ... INTO isn't supported, according to the docs. Can I > use the dot notation, or something similar? PL/pgSQL doesn't support cursors at all. That's basically a

[SQL] Contribute to the PL/pgSQL CookBook !!

2001-03-15 Thread Roberto Mello
I have started the "PL/pgSQL CookBook" project. The goal is to create a cookbook of PL/pgSQL functions that will be catalogued and made available for others to use and learn from. Come to http://www.brasileiro.net/postgres and contribute your own PL/pgSQL (or PL/Tcl, PL/Perl) func

[SQL] Contribute to the PL/pgSQL CookBook !!

2001-03-15 Thread Roberto Mello
I have started the "PL/pgSQL CookBook" project. The goal is to create a cookbook of PL/pgSQL functions that will be catalogued and made available for others to use and learn from. Come to http://www.brasileiro.net/postgres and contribute your own PL/pgSQL (or PL/Tcl, PL/Perl) fun

Re: [SQL] RE: Help with UPDATE syntax

2001-03-15 Thread Richard Huxton
From: "Michael Davis" <[EMAIL PROTECTED]> > Try eliminating the statement " from user_group_map map". It does not belong in the update. Here is the fully rewritten statement: > > update > user_group_map > set > user_id = 4 > where > user_id = 9 and >

[SQL] Re: Normalization is always good?

2001-03-15 Thread jkakar
Hi Josh, > normal form, most of the time. And I do a few things (such as > polymorhic sub-tables) that would give Fabian Pascal fits :-) Polymorphic sub-tables? =) Do you mean using, for example, one user table that stores different types of users and has some fields specific to only some kinds

Re: [SQL] Re: Normalization is always good?

2001-03-15 Thread Christof Glaser
On Friday, 16. March 2001 00:28, [EMAIL PROTECTED] wrote: > > > Yup. http://www.databasedebunking.com/ Dig through the archives. > > Couldn't find the server... I wonder if it's still there. Try this one: http://www.firstsql.com/dbdebunk/ Regards, Christof -- gl.aser . software engi

Re: [SQL] Re: Normalization is always good?

2001-03-15 Thread Josh Berkus
Jamu, > Polymorphic sub-tables? =) Do you mean using, for example, one user > table that stores different types of users and has some fields > specific to only some kinds of users and other fields that are shared > by all users? Nope. What you described is a "not normalized" table. ;-) One pr

Re: [SQL] List Concatination

2001-03-15 Thread Richard H
On 3/15/01, 5:02:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re: [SQL] List Concatination : > Josh Berkus <[EMAIL PROTECTED]> writes: > >> Note that this is probably not a good idea - the ordering of the > >> contacts will not be well-defined. When I asked about this Tom Lane was > >> qu