Re: [SQL] Full outer join
Tim Perdue <[EMAIL PROTECTED]> writes: > However, I keep getting this error, and I don't know what it means: > ERROR: FULL JOIN is only supported with mergejoinable join conditions Works for me: regression=# create table stats_http_downloads (day int, filerelease_id int); CREATE regression=# create table stats_ftp_downloads (day int, filerelease_id int); CREATE regression=# SELECT * FROM (stats_http_downloads sh regression(# FULL OUTER JOIN stats_ftp_downloads sf USING (day,filerelease_id)); day | filerelease_id -+ (0 rows) What version are you using? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Full outer join
On Fri, Apr 13, 2001 at 03:02:32AM -0400, Tom Lane wrote: > Tim Perdue <[EMAIL PROTECTED]> writes: > > However, I keep getting this error, and I don't know what it means: > > ERROR: FULL JOIN is only supported with mergejoinable join conditions > > Works for me: > > regression=# create table stats_http_downloads (day int, filerelease_id int); create table stats_http_downloads (day int, filerelease_id int,group_id int, downloads int); > CREATE > regression=# create table stats_ftp_downloads (day int, filerelease_id int); create table stats_ftp_downloads (day int, filerelease_id int,group_id int, downloads int); > CREATE > regression=# SELECT * FROM (stats_http_downloads sh > regression(# FULL OUTER JOIN stats_ftp_downloads sf USING (day,filerelease_id)); > day | filerelease_id > -+ > (0 rows) > > > What version are you using? That's RC3 and RC1. I wonder if the problem is because stats_http_downloads and stats_ftp_downloads both have group_id and downloads, which I don't want to use as part of the join. Does it still work with those revised CREATE statements? Tim -- Founder - PHPBuilder.com / Geocrawler.com Lead Developer - SourceForge VA Linux Systems ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[SQL] Re: Update
Tom Lane wrote: > Kyle <[EMAIL PROTECTED]> writes: > > It appears that the first function would get evaluated first under 7.0.3 > > but the last function gets evaluated first under 7.1. Is that accurate? > > Actually, I was under the impression that (all else being equal) WHERE > clauses would get evaluated right-to-left in 7.0.* as well. I was > meaning to figure out where the clause order reversal is happening and > undo it, but didn't get around to it for 7.1. > > > Is there a way to control which functions are given precidence? > > Nope, not at the moment. The code has remnants of a notion of cost of > evaluation for functions, but it's not being used for anything ... > Might be interesting to have something like: create function ... as ... with cost=x; It would also be cool to supply a default set of parameters to the function. Then "vaccum analyze" or some such thing could execute the functions, time them, and store cost data internally... create function ... as ... with default(3,7,4); or create function myfunc (int4 3, float8 7, numeric 4) ...; BTW, great job on 7.1! Kudos to all the developers who are working so hard to make it happen. begin:vcard n:Bateman;Kyle x-mozilla-html:FALSE org:Action Target Inc. adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:President x-mozilla-cpt:;0 fn:Kyle Bateman end:vcard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Debian Package problems
Does anybody know what's going on with the Debian 7.1 RC4 packages? It will not let me create any users or even talk to the backend. If I try to create a user (as user postgres), it asks me for a password, but it's not the UNIX password because I tried that (I changed the password right after I installed the packages). If I try to connect through psql, it asks me for the password again. It looks like it's using password auth instead of ident auth, which used to be the default. There's nothing pointed in the packages web pages, a caveat or anything. I've looked. Thanks, -Roberto -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club |--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer Ad astra, per ardua nostra. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] Debian Package problems
On Fri, Apr 13, 2001 at 09:00:45AM -0600, Roberto Mello wrote: > If I try to connect through psql, it asks me for the password again. > It looks like it's using password auth instead of ident auth, which used > to be the default. > There's nothing pointed in the packages web pages, a caveat or > anything. I've looked. Okay, I feel dumb now. It looks like Oliver Elphick (the package maintainer) changed the default authentication methods. Before local users were "trust" now they are "password". Thing is, if it's password, how do you know the password for user postgres? This (a note) should be in the package pages, or at least told the user during upgrade. -Roberto -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club |--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer Go FORTH and C PASCAL play COBOL with an APL. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] Full outer join
Tim Perdue <[EMAIL PROTECTED]> writes: > Does it still work with those revised CREATE statements? Yes, works fine here. >> What version are you using? > That's RC3 and RC1. Curious. I'd expect this to happen for column datatypes whose '=' operator isn't marked mergejoinable, but plain old int certainly doesn't have that problem. I think there's something you haven't told us. Is either of these tables actually a view? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Full outer join
On Fri, Apr 13, 2001 at 11:11:26AM -0400, Tom Lane wrote: > Tim Perdue <[EMAIL PROTECTED]> writes: > > Does it still work with those revised CREATE statements? > > Yes, works fine here. > > >> What version are you using? > > > That's RC3 and RC1. > > Curious. I'd expect this to happen for column datatypes whose '=' > operator isn't marked mergejoinable, but plain old int certainly doesn't > have that problem. I think there's something you haven't told us. Is > either of these tables actually a view? Hehe - no. I sent the \d of both tables at the bottom of that email. Tim -- Founder - PHPBuilder.com / Geocrawler.com Lead Developer - SourceForge VA Linux Systems ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] Debian Package problems
Roberto Mello wrote: >On Fri, Apr 13, 2001 at 09:00:45AM -0600, Roberto Mello wrote: > >>If I try to connect through psql, it asks me for the password again. >> It looks like it's using password auth instead of ident auth, which used >> to be the default. >>There's nothing pointed in the packages web pages, a caveat or >> anything. I've looked. > > Okay, I feel dumb now. > It looks like Oliver Elphick (the package maintainer) changed the >default authentication methods. Before local users were "trust" now they >are "password". > Thing is, if it's password, how do you know the password for user >postgres? > This (a note) should be in the package pages, or at least told the user > >during upgrade. Noted. If you do export PGHOST=localhost you will be able to connect without a password, using the default method. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "I sought the LORD, and he heard me, and delivered me from all my fears."Psalms 34:41 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [SQL] Full outer join
Tim Perdue <[EMAIL PROTECTED]> writes: >> Is either of these tables actually a view? > Hehe - no. I sent the \d of both tables at the bottom of that email. \d isn't very helpful for these sorts of reports. How about pg_dump -s ? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] 7.1 grant/revoke speed
Kyle <[EMAIL PROTECTED]> writes: > Any reason why I should expect grants and/or revokes to be slower under > 7.1RC3? > I have a script that grants all our privileges and it takes about 5 to > 10 times longer to run than it did under 7.0.3. Seems unlikely that the problem is with the grants/revokes per se; probably the slowdown is elsewhere. Have you looked for changes in the EXPLAIN results for the queries being used? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] Debian Package problems
On Fri, Apr 13, 2001 at 11:38:18AM -0400, Stan Brown wrote: > I don;t have a clue. But I also am having fits with the Debian package for > "stable" It installs fine, and then I su to postgres. At that point in time > psql will connect, but createuser fails :-( > > I would be interested in what yu find out. I changed /etc/postgresql/pg_hba.conf so that local users are "trust" again (instead of password). You are looking for this line (already changed): localalltrust That's probably not the safest way, but now that I can do something (because postgres can actually talk to the DB), I will change it back to password. > Windows 98: n. > useless extension to a minor patch release for 32-bit extensions and > a graphical shell for a 16-bit patch to an 8-bit operating system > originally coded for a 4-bit microprocessor, written by a 2-bit > company that can't stand for 1 bit of competition. :) Remarkably accurate! -Roberto -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club |--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer C program run. C program crash. C programmer quit. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[SQL] BOOLEAN data type?
Folks: I had assumed that the BOOL column type was a tru boolean. That is, I wrote some functions on the understand that, given table def: CREATE TABLE order_details ( order_detail_id SERIAL NOT NULL PRIMARY KEY, detail_id INT4 NOT NULL, order_usq INT4 NOT NULL, detail_required BOOL DEFAULT FALSE ); That the following query: SELECT detail_id FROM order_detials WHERE order_usq = 7703 AND detail_required; ... should be equivalent to: SELECT detail_id FROM order_detials WHERE order_usq = 7703 AND detail_required = TRUE; However, in testing (7.1 RC2), the query turned out to mean this: SELECT detail_id FROM order_detials WHERE order_usq = 7703 AND detail_required IS NOT NULL; ... throwing off a lot of my results until I figured it out. Can someone explain this to me? I thought the whole point of a BOOL data type was that it could be treated as a Boolean value, and used for testing and comparison without and "= TRUE" or "= FALSE". What's going on here? -Josh __AGLIO DATABASE SOLUTIONS___ Josh Berkus Complete information technology [EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businessesfax 621-2533 and non-profit organizations. San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [SQL] BOOLEAN data type?
Josh Berkus writes: > That the following query: > > SELECT detail_id FROM order_detials > WHERE order_usq = 7703 AND detail_required; > > ... should be equivalent to: > > SELECT detail_id FROM order_detials > WHERE order_usq = 7703 AND detail_required = TRUE; > > However, in testing (7.1 RC2), the query turned out to mean this: > > SELECT detail_id FROM order_detials > WHERE order_usq = 7703 AND detail_required IS NOT NULL; No way. You're doing something wrong. How about showing the data that makes you believe this? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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
Mailing list gripes (was Re: [SQL] Re: Maybe a Bug, maybe bad SQL)
Louis-David Mitterrand <[EMAIL PROTECTED]> writes: > As if subject mangling and annoying footers were not enough. You can turn off subject mangling in your subscription preferences. If you haven't gone through majordomo's "help set" info recently, you might spend the time to do so --- there's a lot of interesting new preference options in recent majordomo releases. I find setting subscription class = UNIQUE particularly helpful to handle subscriptions to multiple pgsql lists. I haven't looked to see if the footers can be turned off or not. Personally I'd vote for losing them altogether... > I wish people could also lose the preaching in their signatures. Amen, brother ;-) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] RE: RE: Re: select substr???
Jeff Eckermann <[EMAIL PROTECTED]> writes: > You are correct, the check for "$1 is null" is not required. I was > attempting an optimisation, as in "don't do anything else if this is null". > The gain would depend on how much further processing the function would > attempt before recognizing that it was dealing with a null value, which is > something that I don't know enough to tell. In 7.1, checking for null would be appropriate unless you've declared the function "strict". A strict function won't even be called for null input, rather a null result will be assumed automatically --- with much less overhead than an explicit test for null would need. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Calling plSQL functions
Lonnie Cumberland <[EMAIL PROTECTED]> writes: > I have then created a PL/pgSQL function called "register_user()" in a file > called register.sql > create function register_user(text,text,text,text,text,text,text,text,text) > [snip] > begin > -- Look to see if the login is already taken > select * from user_info where login = client_login; > ERROR: unexpected SELECT query in exec_stmt_execsql() The error message isn't very helpful, but the issue here is that you're doing a completely useless SELECT --- or at least plpgsql thinks it's useless, because you're discarding the result. (I think that plpgsql is being overly anal-retentive about it, since such a query might indeed be useful if you then examine FOUND or ROW_COUNT, but that's the issue at the moment.) Try making it a SELECT INTO instead. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] Calling plSQL functions
Thanks for the info Tom, I found that same solution just after I had sent this message to the mailing list. I set up a RECORD variable that should receive the results, but the documentation is unclear as to if the variable will receive ALL of the results from the query of just the first result from the query. Actually I have the need at different places in my functions to sometimes work on the list items returned from a query and also have the need to just work on the first result returned by a query. Can you please tell me how these two can easily be done? Cheers, Lonnie --- Tom Lane <[EMAIL PROTECTED]> wrote: > Lonnie Cumberland <[EMAIL PROTECTED]> writes: > > I have then created a PL/pgSQL function called "register_user()" in a file > > called register.sql > > > create function register_user(text,text,text,text,text,text,text,text,text) > > [snip] > > begin > > > -- Look to see if the login is already taken > > select * from user_info where login = client_login; > > > ERROR: unexpected SELECT query in exec_stmt_execsql() > > The error message isn't very helpful, but the issue here is that you're > doing a completely useless SELECT --- or at least plpgsql thinks it's > useless, because you're discarding the result. (I think that plpgsql is > being overly anal-retentive about it, since such a query might indeed be > useful if you then examine FOUND or ROW_COUNT, but that's the issue at > the moment.) Try making it a SELECT INTO instead. > > regards, tom lane __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Calling plSQL functions
Lonnie Cumberland <[EMAIL PROTECTED]> writes: > Actually I have the need at different places in my functions to > sometimes work on the list items returned from a query and also have > the need to just work on the first result returned by a query. SELECT ... LIMIT 1 will serve the second need. For the first, perhaps use the FOR ... loop construct in plpgsql. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Calling plSQL functions
Lonnie, Tom:
Here's a somewhat complicated example of what Tom's talking about from
my own programs.
HOWEVER, you should use this kind of structure sparingly, if at all.
SQL is a declarative language, rather than a procedural one. For
updates to groups of records, you should put the updates in sets and use
declarative statements whenever possible, rather than a looping
structure.
If you find you *have* to do a lot of looping rather than taking a
declarative approach, you might want to consider changing languages.
PL/perl, PL/TCL and C are all much better equipped to handle loops and
arrays than PL/pgSQL and SQL.
The example, part of a 279-line function which calculates a weighted job
score evaluation for an HR database:
--Calculate DETAILS modifier
--loop through details one at a time, adding to candidates
--that have that detail
count_odetails := count_details - COALESCE(count_rdetails, 0);
IF count_odetails > 0 THEN
insert_loop := 0;
WHILE insert_loop < count_odetails LOOP
SELECT detail_id INTO detail_no
FROM order_details
WHERE order_usq = v_order AND detail_req = FALSE
ORDER BY detail_id
LIMIT 1 OFFSET insert_loop;
insert_loop := insert_loop + 1;
UPDATE matches SET match_score = match_score +
(20::NUMERIC/CAST(count_details AS
NUMERIC))
FROM candidate_details
WHERE candidate_details.candidate_usq =
matches.candidate_usq
AND match_sq = match_id
AND detail_id = detail_no;
END LOOP;
END IF;
(NOTE: OFFSET will not accept any math if set dynamically {as above}.
Thus, "LIMIT 1 OFFSET insert_loop + 1" will error).
-Josh
--
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [SQL] Calling plSQL functions
Thanks for the code snippet Josh,
I'll give this method a try as it is only for a simple listing and will not
have to do too many things special.
Cheers
Lonnie
--- Josh Berkus <[EMAIL PROTECTED]> wrote:
> Lonnie, Tom:
>
> Here's a somewhat complicated example of what Tom's talking about from
> my own programs.
>
> HOWEVER, you should use this kind of structure sparingly, if at all.
> SQL is a declarative language, rather than a procedural one. For
> updates to groups of records, you should put the updates in sets and use
> declarative statements whenever possible, rather than a looping
> structure.
>
> If you find you *have* to do a lot of looping rather than taking a
> declarative approach, you might want to consider changing languages.
> PL/perl, PL/TCL and C are all much better equipped to handle loops and
> arrays than PL/pgSQL and SQL.
>
> The example, part of a 279-line function which calculates a weighted job
> score evaluation for an HR database:
>
> --Calculate DETAILS modifier
> --loop through details one at a time, adding to candidates
> --that have that detail
>
> count_odetails := count_details - COALESCE(count_rdetails, 0);
>
> IF count_odetails > 0 THEN
> insert_loop := 0;
> WHILE insert_loop < count_odetails LOOP
>
> SELECT detail_id INTO detail_no
> FROM order_details
> WHERE order_usq = v_order AND detail_req = FALSE
> ORDER BY detail_id
> LIMIT 1 OFFSET insert_loop;
>
> insert_loop := insert_loop + 1;
>
> UPDATE matches SET match_score = match_score +
> (20::NUMERIC/CAST(count_details AS
> NUMERIC))
> FROM candidate_details
> WHERE candidate_details.candidate_usq =
> matches.candidate_usq
> AND match_sq = match_id
> AND detail_id = detail_no;
>
> END LOOP;
> END IF;
>
> (NOTE: OFFSET will not accept any math if set dynamically {as above}.
> Thus, "LIMIT 1 OFFSET insert_loop + 1" will error).
>
> -Josh
>
> --
> __AGLIO DATABASE SOLUTIONS___
> Josh Berkus
>Complete information technology [EMAIL PROTECTED]
> and data management solutions (415) 565-7293
>for law firms, small businesses fax 621-2533
> and non-profit organizations. San Francisco
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[SQL] bound variables with PHP?
I haven't found away to use prepared statements with PHP4 and Postgres - any way to do so? I have an SQL statement I'd prefer to parse outside a loop, ala the prepare and exec statements of dbi. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[SQL] Bug in user management?
I need some information about PostgreSQL user management. I have created a user called epi who is not allowed to create database but allowed to create users. I have connected as user epi and have then created user kertal with the following command: shop=# CREATE USER kertal WITH PASSWORD 'anypasswd' CREATEDB CREATEUSER IN GROUP cybertec; According to the system table kertal is allowed to create databases - I have also tried this as user kertal and it works. In my opinion a user that has not the right to create database MUST NOT create user that are allowed to do it. Have I done something wrong or is it a bug? Hans persons=# SELECT * FROM pg_user ; usename | usesysid | usecreatedb | usetrace | usesuper | usecatupd | passwd | valuntil --+--+-+--+--+---+--+-- postgres | 26 | t | t | t | t | | hans | 27 | f | f | f | f | | epi | 28 | f | f | t | t | | kertal | 29 | t | f | t | t | | (4 rows) -- --- Cybertec Geschwinde &. Schönig OEG; Schönbrunnerstraße 133/18 A-1050 Wien; http://postgres.cybertec.at; Fax.: +43/1/961 71 58 Tel.: +43/664/233 90 75
[SQL] Dropping users with no name
I have accidentally created a user with no name. How can I delete this user? I have compiled my attempts below: Hans persons=# SELECT * FROM pg_user; usename | usesysid | usecreatedb | usetrace | usesuper | usecatupd | passwd | valuntil --+--+-+--+--+---+--+-- postgres | 26 | t | t| t| t | | | 27 | f | f| f| f | | (2 rows) persons=# DELETE FROM pg_user where usesysid>26; DELETE 0 persons=# SELECT '$'|| usename||'$' FROM pg_user; ?column? $postgres$ $$ (2 rows) persons=# DROP USER ''; ERROR: parser: parse error at or near "'" ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[SQL] Savepoints
Does PostgreSQL currently support something like savepoints in Oracle? Hans ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[SQL] Re: enumerating rows
Try this
CREATE SEQUENCE just_a_seq;
Select nextval('just_a_seq') as row_no, * from pg_tables ;
drop SEQUENCE just_a_seq;
>
> row_no | column1 | column2 | ...
> ---+-+-+ ...
> 1 | datum11 | datum12 | ...
> 2 | datum21 | datum22 | ...
>... | ... | ... | ...
>
> I didn't find anything in the docs.
>
> TIA, Zoltan
>
---(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
[SQL] SELECT query
I have three table called table1, table2, table3 all having fields like: table1 contain id and username and id referencing table4 table2 contains id and parallel_username and id referencing table4 table3 contains id and other_username and id referencing table4 table4 is the main table containing id as primary key I want to develop a search engine which shows unique record after searching all the three table but shouldn't contain multiple answers for same SEARCH for username Pls help me, -Regards, Sharmad -- The secret of the universe is @*&í!'ñ^#+ NO CARRIER ___ _ _ _ |_|_||_||_||\/||_|| \ _|| || || \| || ||_/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Problem in writing functions
Hi, I am writing a function in postgresql which inserts a row into the database, but it is not working, can anybody help me out with a simple example. thanx a lot. Kris. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Savepoints
> Does PostgreSQL currently support something like savepoints in Oracle? No, sorry, but we know we need them. -- 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://www.postgresql.org/search.mpl
Re: [SQL] Bug in user management?
=?iso-8859-1?Q?Hans=2DJ=FCrgen=20Sch=F6nig?= <[EMAIL PROTECTED]> writes: > I have created a user called epi who is not allowed to create database > but allowed to create users. The "CREATEUSER" option is rather badly mislabeled: the privilege it actually grants is superuser status. You are laboring under a severe misapprehension if you think that epi has ANY restrictions on what he can do ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Problem in writing functions
Kris, > I am writing a function in postgresql which inserts a row into the > database, > but it is not working, can anybody help me out with a simple example. Please post your function. I'm sure the folks can take a crack at it. -Josh __AGLIO DATABASE SOLUTIONS___ Josh Berkus Complete information technology [EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businessesfax 621-2533 and non-profit organizations. San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
