Re: [SQL] Subselect and limit/order?

2000-08-07 Thread Philip Warner
At 11:46 7/08/00 -0400, Tom Lane wrote: > >I'd say mostly an executor problem, actually. Nobody's figured out >where the executor would need to be hacked to support tuple-limits >applied elsewhere than the top level of a select. Shouldn't the optimizer be able to get some benefit (in colun selec

Re: [SQL] Subselect and limit/order?

2000-08-07 Thread Philip Warner
At 11:46 7/08/00 -0400, Tom Lane wrote: >Philip Warner <[EMAIL PROTECTED]> writes: >> Just wondering why subselect expressions can not have a limit/order clause, > >We could ignore the spec and implement this as an extension, but I'd >want to see some fairly compelling arguments why it's a good id

[SQL] PL/pgSQL

2000-08-07 Thread Jie Liang
Hi, there, 1. Is anybody know how to declare a explicit cursor in PL/SQL in postgres? 1. I want create a function use PL/pgSQL: create function foo() returns whatevertype as ' declare v_asda int2; cursor is select a,b,c from AAA; -- what is the syntex? begin statements end; ' langauge 'plp

Re: [SQL] foreign key take too much time to check

2000-08-07 Thread Mark Volpe
Try creating the tables without the constraint first, then populate them, and then add the foreign key constaint as the last step using ALTER TABLE/ADD CONSTRAINT. Mark Jie Liang wrote: > > Hi, there, > > I want add a constraint to my tables: > I have 2 tables: > 1. Table_A(id int 4 primary k

[SQL] foreign key take too much time to check

2000-08-07 Thread Jie Liang
Hi, there, I want add a constraint to my tables: I have 2 tables: 1. Table_A(id int 4 primary key, item text, ..), 2. Table_B(id int4, cid int4, constraint b_fk foreign key (id) refereneces Table_A(id) on delete cascade on update cascade); Table_A has ~900,000 rows, Table_B has ~1,200,000

[SQL] Changing user passwords

2000-08-07 Thread Rob van der Leek
Hello, Is it possible to change a user's password without using the pg_passwd command? For example, how does a user changes his password from the interactive monitor? In case you were wondering, I'm scripting an interface to a pg database using Perl/DBI and the "administrator" web user should be

Re: [SQL] Functions too slow, even with iscachable?

2000-08-07 Thread Tom Lane
Philip Warner <[EMAIL PROTECTED]> writes: > At 10:58 7/08/00 -0400, Tom Lane wrote: >> Looks like we need to teach the optimizer that expressions involving >> params can be treated like simple params for the purposes of >> optimization. > So long as the function is cacheable... Yes, of course --

Re: [SQL] Functions too slow, even with iscachable?

2000-08-07 Thread Philip Warner
At 10:58 7/08/00 -0400, Tom Lane wrote: > >Looks like we need to teach the optimizer that expressions involving >params can be treated like simple params for the purposes of >optimization. > So long as the function is cacheable...

Re: [SQL] Functions too slow, even with iscachable?

2000-08-07 Thread Tom Lane
Ang Chin Han <[EMAIL PROTECTED]> writes: > I have a query which runs fast: > SELECT passwd FROM ticket WHERE name = ticket2name('test-006kdt') AND > survey_id = ticket2survey_id('test-006kdt'); > But slows down to a crawl when I wrapped it in a function: > CREATE FUNCTION ticket2passwd(text)

Re: [SQL] Functions too slow, even with iscachable?

2000-08-07 Thread Ross J. Reedstrom
On Mon, Aug 07, 2000 at 05:11:10PM +0800, Ang Chin Han wrote: > I have a query which runs fast: > > SELECT passwd FROM ticket WHERE name = ticket2name('test-006kdt') AND > survey_id = ticket2survey_id('test-006kdt'); > > But slows down to a crawl when I wrapped it in a function: > > CREATE

[SQL] Subselect and limit/order?

2000-08-07 Thread Philip Warner
Just wondering why subselect expressions can not have a limit/order clause, eg. select id,(select id from tbl where id > ? order by id limit 1) as nextid from tbl where id = ?; is quite usefull. It can obviously be done in two select statements, but I was just wondering if it's an ove

Re: [SQL] Functions too slow, even with iscachable?

2000-08-07 Thread Philip Warner
At 17:11 7/08/00 +0800, Ang Chin Han wrote: > >BTW, pg_dump doesn't seem to preserve the iscachable attribute. Bug? > Here is a patch for 7.0.2 sources which adds support for ischachable to pg_dump. - diff -Naur pg_dump/pg_dump.c zzz/pg_dump.c ---

Re: [SQL] Functions too slow, even with iscachable?

2000-08-07 Thread Philip Warner
At 17:11 7/08/00 +0800, Ang Chin Han wrote: > >BTW, pg_dump doesn't seem to preserve the iscachable attribute. Bug? > Don't know about the rest of your message, but this seems to be a bug. I'll look into it some more... Philip War

[SQL] Functions too slow, even with iscachable?

2000-08-07 Thread Ang Chin Han
I have a query which runs fast: SELECT passwd FROM ticket WHERE name = ticket2name('test-006kdt') AND survey_id = ticket2survey_id('test-006kdt'); But slows down to a crawl when I wrapped it in a function: CREATE FUNCTION ticket2passwd(text) RETURNS text AS 'SELECT passwd FROM ticket WH