returning tuples thus it'd be applied
for only SELECT or DML with RETURNING. So I'm +1 for non-fix but
redefine the behavior. Who wants to limit the number of rows
processed inside the backend, from SPI?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
The following bug has been logged online:
Bug reference: 6172
Logged by: Hitoshi Harada
Email address: umi.tan...@gmail.com
PostgreSQL version: 9.1RC1
Operating system: Windows7
Description:DROP EXTENSION error without CASCADE
Details:
On pure-installed RC1
The following bug has been logged online:
Bug reference: 6139
Logged by: Hitoshi Harada
Email address: umi.tan...@gmail.com
PostgreSQL version: 8.2+
Operating system: Any
Description:LIMIT doesn't return correct result when the value is
huge
Details:
db1=# select
that have internal for aggtranstype.
So, is it better to generalize as it adds ALLOCSET_DEFAULT_INITSIZE if
the transtype is internal, rather than specifying individual function
OID as the patch stands?
Regards,
--
Hitoshi Harada
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
need
to specify a different window frame.
regards, tom lane
And it's well-documented. See
http://www.postgresql.org/docs/8.4/static/functions-window.html
--
Hitoshi Harada
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
the 1. ROW(...) construction seems not valid.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Regards,
--
Hitoshi Harada
