Materialized views (Was Re: [HACKERS] Improving count(*))
On Fri, 18 Nov 2005, Josh Berkus wrote: Alvaro, I guess there must be a query-rewriting mechanism for implementing materialized views. With that in place we may be able to implement this other thing ... Is anybody working on materialized views? I have a bundle of academic code designed to do exactly this, if any hacker wants to take on the task of getting it into production shape. Could you post it to the list? I'd be interested to take a look, though I'm afraid don't have the time to work on it. I've been reading some papers on materialized views lately. Here's some interesting ones: Blakeley, Larson, Tompa: Efficiently Updating Materialized View http://tinyurl.com/8hqeo Describes a fairly simple algorithm for keeping select-project-join views up to date. Vista: View Maintenance in Relational and Deductive Databases by Incremental Query Evaluation http://tinyurl.com/exb8o A survey of various algorithms. Gupta, Mumick, Subrahmanian: Maintaining Views Incrementally http://portal.acm.org/citation.cfm?id=170066 Extended abstract of a paper that presents two algorithms: one similar to the Blakeley paper, and another one that can also handle recursion. Ross, Srivastava, Sudarshan: Materialized View Maintenance and Integrity Constraint Checking: Trading Space for Time http://citeseer.ist.psu.edu/ross96materialized.html Describes how materialized views can be used for implementing database assertions. - Heikki ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] request for enhancement of protocol
Hello Meybe is time for some changes. Maybe. I haven't courage for it. But maybe is good time for discussion. What I miss in protocol? 1. debug. support + other level for elog. Current elog is too heavy (sometimes) 2. multi result sets. This is necessery for support procedures in DB2, MySQL, ANSI, MsSQL style. 3. session (package) variables and calling procedures with OUT, INOUT in normal style, tj. stmt CALL. - heavy task, because I can write function a(IN int, IN int), and a(OUT int, OUT int) now. This is problem, and need restriction. 4. ping What is my motivation for 2? 1. I can write solution - stored application. Example: info about growing of database. Output is n tables: first table is info about database, others about top n - 1 tables, ... 2. easy reporting. I haven't possibility write stored procedure for generating cross table now. I have to do all in two steps (example): generate view, select from view. This is difference between procedures and functions. Function have to have exactly defined interface. Procedures can't. 3. easy porting from databases which support this style. sorry for my wrong english. best regards Pavel Stehule _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] request for enhancement of protocol
On Sat, Nov 19, 2005 at 11:07:58AM +0100, Pavel Stehule wrote: Hello Meybe is time for some changes. Maybe. I haven't courage for it. But maybe is good time for discussion. What I miss in protocol? 1. debug. support + other level for elog. Current elog is too heavy (sometimes) What do you mean? There are already 10 levels for elog, including five levels of DEBUG. How many more do you want? 2. multi result sets. This is necessery for support procedures in DB2, MySQL, ANSI, MsSQL style. The protocol already supports this and libpq does also. However, I think that unless you are using async mode you may have difficulty retrieving it. There's also a comment there about whether the backend can actually do it, so maybe some work need to be done there. 3. session (package) variables and calling procedures with OUT, INOUT in normal style, tj. stmt CALL. - heavy task, because I can write function a(IN int, IN int), and a(OUT int, OUT int) now. This is problem, and need restriction. I can understand the CALL but what's the confusing between the two functions a? One is a(1,2), the other is a(). 4. ping You mean, a ping command without requiring a login? What is my motivation for 2? 1. I can write solution - stored application. Example: info about growing of database. Output is n tables: first table is info about database, others about top n - 1 tables, ... So you mean a function that can return anything (and hence cannot be used in normal queries). And thus define a special interface for it (CALL). Still, SELECT function() would work just as well, no? 2. easy reporting. I haven't possibility write stored procedure for generating cross table now. I have to do all in two steps (example): generate view, select from view. Why do you need a view, why can't you use a subquery? This is difference between procedures and functions. Function have to have exactly defined interface. Procedures can't. So essentially, procedures here are functions that return unknown rather than functions that return nothing? 3. easy porting from databases which support this style. Ok, valid point. Interesting points all, but they seem to be more backend related than protocol related. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpZFiKc9Iloy.pgp Description: PGP signature
Re: [HACKERS] request for enhancement of protocol
What do you mean? There are already 10 levels for elog, including five
levels of DEBUG. How many more do you want?
sometimes I need show only some text. Now I get stack info.
lighter elog ~ sending text, not. proc, stack info.
2. multi result sets. This is necessery for support procedures in DB2,
MySQL, ANSI, MsSQL style.
The protocol already supports this and libpq does also. However, I
think that unless you are using async mode you may have difficulty
retrieving it. There's also a comment there about whether the backend
can actually do it, so maybe some work need to be done there.
libpq is black box for me :-(. I need support in psql and plpgsql. And not
in
async mode, or I need wraper over async mode:
multih = execute_multi('call somestoredproc');
while not (rec = fetch_rs(multih))
{
...
}
3. session (package) variables and calling procedures with OUT, INOUT in
normal style, tj. stmt CALL. - heavy task, because I can write function
a(IN int, IN int), and a(OUT int, OUT int) now. This is problem, and
need
restriction.
I can understand the CALL but what's the confusing between the two
functions a? One is a(1,2), the other is a().
when I can use variables (in plpgsql now, in sql in future - package
variables) I have to remember form of function. I can't to call a(@x1, @x2).
Why. Caller don't know if I mean variant one or variant two. And I have to
use nonstandard convension select into a(). Nonstandard in separation in and
out variables. I prefere some restriction here.
4. ping
You mean, a ping command without requiring a login?
yes
What is my motivation for 2?
1. I can write solution - stored application. Example: info about
growing of database. Output is n tables: first table is info about
database, others about top n - 1 tables, ..
So you mean a function that can return anything (and hence cannot be
used in normal queries). And thus define a special interface for it
(CALL). Still, SELECT function() would work just as well, no?
SELECT works well if I expect scalar value. But if I expect table I have to
use diff. form
SELECT * FROM ... I see two modes of calling a) select - typed result, b)
call - untyped result. For point a I have different requirements than for
point b. And I see difference between statement call (clauses where, from,
.) and statement call. PostgreSQL don't support procedures now, only
functions.
2. easy reporting. I haven't possibility write stored procedure for
generating cross table now. I have to do all in two steps (example):
generate view, select from view.
Why do you need a view, why can't you use a subquery?
if you have to solve creating cross table for normal interactive using in
console, you have two possibilities: 1. call stored procedure which generate
temp wiew and user will do select from view, or procedure can create cursor
and user will do select from cursor. But you can't do in one procedure now.
This is difference between procedures and functions. Function have to
have exactly defined interface. Procedures can't.
So essentially, procedures here are functions that return unknown
rather than functions that return nothing?
yes. This is reason why procedures can't to use in select statement
3. easy porting from databases which support this style.
Ok, valid point.
Interesting points all, but they seem to be more backend related than
protocol related.
I spent some time for looking way for implementing this into plpgsql. I
didn't find it. It's part of SPI too.
Pavel
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] request for enhancement of protocol
On Sat, Nov 19, 2005 at 12:40:23PM +0100, Pavel Stehule wrote:
What do you mean? There are already 10 levels for elog, including five
levels of DEBUG. How many more do you want?
sometimes I need show only some text. Now I get stack info.
lighter elog ~ sending text, not. proc, stack info.
You could turn the log_error_verbosity down so it doesn't show stack
info.
The protocol already supports this and libpq does also. However, I
think that unless you are using async mode you may have difficulty
retrieving it. There's also a comment there about whether the backend
can actually do it, so maybe some work need to be done there.
Actually, I played with some functions in 8.1 and this is possible:
test=# create or replace function test(int4) returns setof unknown as
$$declare
a record;
begin
select into a * from pg_attribute limit 1;
return next a;
return next (1,2,4);
return next ('hello','world');
return next 'plain string';
return; end$$
language plpgsql;
CREATE FUNCTION
test=# select * from test(1);
test
---
(1247,typname,19,-1,64,1,0,-1,-1,f,p,i,t,f,f,t,0)
(1,2,4)
(hello,world)
plain string
(4 rows)
Ok, not maybe the neatest way of doing it, but it works right now.
3. session (package) variables and calling procedures with OUT, INOUT in
normal style, tj. stmt CALL. - heavy task, because I can write function
a(IN int, IN int), and a(OUT int, OUT int) now. This is problem, and
need
restriction.
I can understand the CALL but what's the confusing between the two
functions a? One is a(1,2), the other is a().
when I can use variables (in plpgsql now, in sql in future - package
variables) I have to remember form of function. I can't to call a(@x1,
@x2). Why. Caller don't know if I mean variant one or variant two. And I
have to use nonstandard convension select into a(). Nonstandard in
separation in and out variables. I prefere some restriction here.
Hmm, I searched the standard for package variable but couldn't find it.
Does the syntax have to do that? What if you have an INOUT parameter
and you want the output to go to a different place than the input.
Wouldn't:
SELECT INTO @x1, @x2 from a();
SELECT * from a(@x1,@x2);
be less ambiguous?
SELECT works well if I expect scalar value. But if I expect table I have to
use diff. form
SELECT * FROM ... I see two modes of calling a) select - typed result, b)
call - untyped result. For point a I have different requirements than for
point b. And I see difference between statement call (clauses where, from,
.) and statement call. PostgreSQL don't support procedures now, only
functions.
As pointed out above, PostgreSQL does support untyped results, just as
long as you don't try to pass it to any other functions.
if you have to solve creating cross table for normal interactive using in
console, you have two possibilities: 1. call stored procedure which
generate temp wiew and user will do select from view, or procedure can
create cursor and user will do select from cursor. But you can't do in one
procedure now.
You mean a crosstab query like in contrib/tablefunc? That doesn't
require creating a view. But then, that may not be what you want.
I spent some time for looking way for implementing this into plpgsql. I
didn't find it. It's part of SPI too.
I imagine in SPI you could unpack the sets returned by functions
returing unknown, but I havn't tried that.
Have a nice day,
--
Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/
Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.
pgpgwg68vS6i5.pgp
Description: PGP signature
Re: Materialized views (Was Re: [HACKERS] Improving count(*))
(CCed to the matview-devel mailing list) On 11/19/05, Heikki Linnakangas [EMAIL PROTECTED] wrote: I've been reading some papers on materialized views lately. Here's some interesting ones: (snip) You might want to take a look at the pages that I set up to track the progress on my master's thesis: url:http://www.nicolas.barbier.easynet.be/itsme/thesis/ especially the literature page: url:http://www.nicolas.barbier.easynet.be/itsme/thesis/literature/ IMO, GL95, Qua97 and GM99 are the ones that are most applicable to view maintenance with bag-semantics (thus, SQL). You should be able to find all these papers with Google (Scholar) in case my computer is shut down, otherwise you can download them directly from me. Greetings, Nicolas -- Nicolas Barbier http://www.gnu.org/philosophy/no-word-attachments.html ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] request for enhancement of protocol
i think if the protocol is enhanced again we should also consider adding protocol level support for RESET CONNECTION. i have sent this patch some time ago but i think it is not worth to do the remaining protocol level changes (sql level support is finished) if this is the only change on the protocol level. best regards, hans Pavel Stehule wrote: Hello Meybe is time for some changes. Maybe. I haven't courage for it. But maybe is good time for discussion. What I miss in protocol? 1. debug. support + other level for elog. Current elog is too heavy (sometimes) 2. multi result sets. This is necessery for support procedures in DB2, MySQL, ANSI, MsSQL style. 3. session (package) variables and calling procedures with OUT, INOUT in normal style, tj. stmt CALL. - heavy task, because I can write function a(IN int, IN int), and a(OUT int, OUT int) now. This is problem, and need restriction. 4. ping What is my motivation for 2? 1. I can write solution - stored application. Example: info about growing of database. Output is n tables: first table is info about database, others about top n - 1 tables, ... 2. easy reporting. I haven't possibility write stored procedure for generating cross table now. I have to do all in two steps (example): generate view, select from view. This is difference between procedures and functions. Function have to have exactly defined interface. Procedures can't. 3. easy porting from databases which support this style. sorry for my wrong english. best regards Pavel Stehule _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Cybertec Geschwinde Schönig GmbH Schöngrabern 134; A-2020 Hollabrunn Tel: +43/1/205 10 35 / 340 www.postgresql.at, www.cybertec.at ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Returning multiple result sets
I've been thinking about this and wondered if this is a way to get it done without too much work. 1. Create an anyrecord type to which any record type can be cast. It's essentially a heaptuple with a tupledesc. 2. anyrecord is opaque to the parser, you cannot dereference it, only output it or pass it to other functions accepting anyrecord. Possibly some dynamic languages may be able to reference these. 3. In the output functions printtup_startup/printtup, if any of the result fields are of type anyrecord it defers the 'T' message until the tuples arrive. When they do it expands the anyrecord and creates columns from each and sends an appropriate 'T' message. 4. libpq already supports multiple result sets so no problem there. The effect of this would be that you get multiple result sets, once for each time the tupledesc changes. As for creating a split without changing, maybe you need to return a special empty tuple which signifies end-of-set. It also occured to me we could just change the record type to do this, but this would change the behaviour of: test=# select x from test() as x; x --- (1,2) (1 row) to: a | b ---+--- 1 | 2 (1 row) But that's backward incompatable. OTOH, it would mean we could get rid of the requirement that functions returning record must specify a column definition list in the query. the only restriction is that you can't dereference it, but that doesn't seem so big a deal. So, kill a few birds with one stone. Any thoughts? -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpB3L9rtneZ4.pgp Description: PGP signature
[HACKERS] Virtual tuple slots versus TOAST: big problem
I looked into this 8.1 bug reported by Alexey Beschiokov: http://archives.postgresql.org/pgsql-bugs/2005-11/msg00192.php The executive summary is: it looks like a kluge solution isn't hard, but solving it in a more reasonable fashion is going to require some significant API changes inside the backend :-( The problem is that ExecInsert() does ExecMaterializeSlot() to get a physical tuple from the virtual tuple slot it's initially handed. After this step, the TupleTableSlot contains that same physical tuple. ExecInsert then passes the bare tuple to some subroutines and the Slot to other subroutines. In the particular case shown by Alexey, the sequence is: ExecConstraints is called with the slot heap_insert (and thence tuptoaster.c) is called with the bare tuple ExecInsertIndexTuples is called with the slot The problem is that ExecConstraints accesses some fields of the slot, causing partial extraction of tuple fields and setup of the tts_values[] array within the slot. After that, the tuptoaster proceeds to smash down the tuple to a size it likes, which it does by scribbling on the HeapTuple structure it's handed. That makes the TupleTableSlot structure inconsistent --- it has tts_values fields pointing at memory that's no longer part of the tuple actually stored in the slot. When ExecInsertIndexTuples then tries to extract more fields from the slot, a crash is not unlikely. (It's annoying that we didn't find this during beta, but a failure requires ExecInsertIndexTuples to try to access fields to the right of the last one fetched by ExecConstraints, and it only matters if the tuple actually got toasted in between, so it is a bit of a corner case.) ExecUpdate has the same bug. I don't think there are any other places, because ExecMaterializeSlot isn't used elsewhere ATM. The problem did not exist before 8.1 because TupleTableSlots didn't contain extra info beyond the bare tuple, so tuptoaster could hack that without rendering the Slot inconsistent. I think that a kluge fix is possible by setting tts_nvalid to zero after invoking heap_insert or heap_update, so that ExecInsertIndexTuples will be forced to recompute tts_values instead of reusing the previous data. This is probably the right thing to do in the 8.1 branch, but it's incredibly ugly and we need to fix it better going forward. A better fix seems to require passing the TupleTableSlot, not just the bare tuple, down to the toaster --- else there is no way for the toaster to update the data structure that it's accidentally invalidating. This seems like it might be a good idea anyway on performance grounds: we could save one cycle of heap_deform_tuple and heap_formtuple in the case where toasting is needed, if the toaster is invoked on the tuple while it's still in virtual-slot format. The problem is that given the current structure, that means changing the APIs of heap_insert and heap_update, or else making near-duplicate versions that take a TupleTableSlot instead of a bare tuple. Neither of these things seem real attractive. If we wanted to avoid forming a physical tuple until the last moment we'd also need to change the APIs associated with triggers, ie make them work on Slots not tuples. This'd be even more invasive. It would likely be cleaner and more efficient in the long run, but there's a lot of code to touch, and breaking user-defined triggers doesn't seem palatable at all. Any thoughts on the best way to proceed? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Returning multiple result sets
Martijn van Oosterhout kleptog@svana.org writes: So, kill a few birds with one stone. Any thoughts? I don't think any of this will actually work :-(. There's too much code that assumes that all the tuples returned by a query are alike, and I for one don't feel like trying to find and fix it all. (Not all of it is within our control, either --- this will break client code along with the backend.) regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Returning multiple result sets
On Sat, Nov 19, 2005 at 12:43:15PM -0500, Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: So, kill a few birds with one stone. Any thoughts? I don't think any of this will actually work :-(. There's too much code that assumes that all the tuples returned by a query are alike, and I for one don't feel like trying to find and fix it all. (Not all of it is within our control, either --- this will break client code along with the backend.) I don't think so, as far as all the functions are concerned, the tuples are all the same: when a function is called with anyrecord, it's passed a single argument, the heaptuple+tupledesc. It's an opaque verlena type that nothing is going to be able to access unless they actually go to the effort. All this does is essentially flatten records-in-tuples in the output function. Consider: create function a(anyrecord) returns anyrecord; create function b(int4) returns anyrecord; select a(b(2)); Does anything in the backend other than those two functions need to know the exact format of the anyrecord? Even if the actual records contain 20 values, to everybody else it's just an opaque verlena type. And in the output (and *only* on output), the printtup function can examine the tupledesc to tell the client what data to expect. Seems like it should be possible to me. Another way to put it would be making records a first-class type. What am I missing? Thanks in advance, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgp3a19ET9cyY.pgp Description: PGP signature
[HACKERS] dropdb lock
In dbcommands.c::dropdb() there are these lines: /* Close pg_database, but keep exclusive lock till commit */ heap_close(pgdbrel, NoLock); However, ISTM that if I return early from that function because the db doesn't exist I should release the lock immediately. Or is there something I have missed? Is that the only cleanup I would need for the IF EXISTS case (looks like it to me)? cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] dropdb lock
Andrew Dunstan [EMAIL PROTECTED] writes: In dbcommands.c::dropdb() there are these lines: /* Close pg_database, but keep exclusive lock till commit */ heap_close(pgdbrel, NoLock); However, ISTM that if I return early from that function because the db doesn't exist I should release the lock immediately. Or is there something I have missed? Should be OK to drop the lock if you didn't change anything. OTOH, it probably doesn't matter much since we don't allow dropdb inside a transaction block; commit is going to happen shortly anyhow. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: Materialized views (Was Re: [HACKERS] Improving count(*))
Heikki, Could you post it to the list? I'd be interested to take a look, though I'm afraid don't have the time to work on it. Yeah, I should put it up on pgFoundry. I'm not sure exactly where, though -- I don't want to launch a new project if it's not going to take off. Maybe Bizgres. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PCTFree Results
Jonah, Do you have an 8.1 patch for this or only the 8.0.x? Nope, this is Satoshi's code, ask him. BTW, I'm not sure that the DBT2 test is ideal for this sort of thing anyway. We really need a few tests that are heavier on UPDATEs than on INSERTS. Maybe a few data warehousing-style merges. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Returning multiple result sets
Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: So, kill a few birds with one stone. Any thoughts? I don't think any of this will actually work :-(. There's too much code that assumes that all the tuples returned by a query are alike, and I for one don't feel like trying to find and fix it all. (Not all of it is within our control, either --- this will break client code along with the backend.) Hmm -- probably we could declare that the current libpq API will not support multiple result sets from one query, and return only the first one to the application discarding the rest. (It just occured to me -- what happens if one send multiple SELECTs in a semicolon-separated query via libpq?). New apps wanting to take advantage of the new functionality would need to invoke a different function. At the protocol level this will need an extension anyway, so clients using the protocol directly would need to be updated to understand multiple results. I know people migrating from SQL Server (maybe others?) are already having trouble because of our inability to return multiple result sets. The sooner we do it, the sooner all the code will be fixed ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] order by, for custom types
On 2005-11-19, Grzegorz Jaskiewicz [EMAIL PROTECTED] wrote: Wildcards cause things not to work as they should consider everything in [] brackets to be a possible choice and those three: a = 1.2.3.4 b = 1.[2,3].3.4 c = 1.3.3.4 a = b, b = c, but a c, I was told that because of that btree won't work on my type. (on irc, that was AndrewSN as I recall). Probably. But nothing stops you defining equality and ordering operators that _do_ work for btree, and hence sorting, it's just that those operators won't be any use for the matching semantics. It's clear that for your data type that there is a concept of equality in which all three of your values a,b,c above are unequal. My advice would be (and I'm sure I suggested this at the time) that you reserve the '=' operator for a true equality operation, and use some other operator such as ~ or @ for the matches semantics that you want for your application. Having an intransitive '=' operator violates the POLA, even if it doesn't actively break anything otherwise (I have no idea if it does). I do have all operators required for btree, no operator class defined, every single operator. Btree requires some function apart from operators, this one is not defined, but I do have = operator as well. You still don't seem to understand that what btree requires is not an operator _called_ '=', but an operator with the logical semantics of equality. That operator can be called anything you please (it doesn't have to have the name '='). Sorting doesn't need an equality operator, since it can fabricate one if given a suitable operator, i.e. one that constitutes a strict weak ordering over the elements to be sorted; it can rely on the fact that NOT(a b) AND NOT(b a) implies that a and b are equivalent for sorting purposes. (The requirement that constitute a strict weak ordering is enough to ensure that this is an equivalence relation, and therefore transitive; if does not meet this requirement then sorting may give wrong answers, loop forever, or possibly crash.) -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Returning multiple result sets
Consider: create function a(anyrecord) returns anyrecord; create function b(int4) returns anyrecord; select a(b(2)); for my task I need little different form :-( create function a(..) returns setof tables but SQL2003 needs type table, and this can be solution _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
