From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
Cc: | pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Order of rows in simple "select r from table_fn()" |
Date: | 2023-02-15 04:34:43 |
Message-ID: | CAFj8pRAWmh5Xz8X8aoKO87_JSbN-UM_mjj92x+5yveSBxms6SQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi
> It adds an uncomfortable amount of clutter.
>
> ** Is it essential for correctness? **
>
> It's annoying that the use of "return next" prevents the pattern that each
> "print line" follows from being encapsulated into a procedure. But it is
> what it is, yes?
>
RETURN NEXT, RETURN QUERY (RETURN QUERY is +/- RETURN NEXT) materializes
result in tuple store. This can be a source of performance problems
sometimes (SELECT * FROM fc() LIMIT n) , but you can believe in persistent
order. Order of reading from the tuple store is exactly like reading from a
file, and there are not any other processes that can modify the order of
reading (tuple store is not visible from other processes). I can imagine
different mechanisms in the future - without materialization based on pipes
- but it is a very far future, and still there will not be a reason for
change of order.
Regards
Pavel
From | Date | Subject | |
---|---|---|---|
Next Message | Bryn Llewellyn | 2023-02-15 05:01:20 | Re: Order of rows in simple "select r from table_fn()" |
Previous Message | Peter Smith | 2023-02-15 04:32:53 | Re: Support logical replication of DDLs |