Pavel Stehule pavel.steh...@gmail.com writes:
I was one who sent a bug report - this error is not too dangerous, but it
is hidden, and difficult to find, if you don't know what can be happen.
Same as bug with plpgsql and SQL identifier collisions. If you understand,
then you can protect self
Tom Lane-2 wrote
Pavel Stehule lt;
pavel.stehule@
gt; writes:
I was one who sent a bug report - this error is not too dangerous, but it
is hidden, and difficult to find, if you don't know what can be happen.
Same as bug with plpgsql and SQL identifier collisions. If you
understand,
then
On 2013-08-30 06:34:47 -0700, David Johnston wrote:
Tom Lane-2 wrote
I was one who sent a bug report - this error is not too dangerous, but it
is hidden, and difficult to find, if you don't know what can be happen.
Same as bug with plpgsql and SQL identifier collisions. If you
understand,
David Johnston pol...@yahoo.com writes:
If we alter syntax for mitigation purposes I'd want to consider requiring
parentheses around the columns that belong to the ORDER BY instead of
using the full extended syntax of WITHIN GROUP.
Unfortunately, that ORDER BY syntax is specified by the SQL
Andres Freund-3 wrote
On 2013-08-30 06:34:47 -0700, David Johnston wrote:
Tom Lane-2 wrote
I was one who sent a bug report - this error is not too dangerous, but
it
is hidden, and difficult to find, if you don't know what can be
happen.
Same as bug with plpgsql and SQL identifier
2013/8/30 David Johnston pol...@yahoo.com
Andres Freund-3 wrote
On 2013-08-30 06:34:47 -0700, David Johnston wrote:
Tom Lane-2 wrote
I was one who sent a bug report - this error is not too dangerous,
but
it
is hidden, and difficult to find, if you don't know what can be
happen.
Uh, the pg_dump part checks for version 80400, shouldn't it be 90400?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Uh, the pg_dump part checks for version 80400, shouldn't it be 90400?
The reasoning there is that 8.4 is where we added
pg_get_function_arguments(), so this dumping code should work against that
server version or later. (Oh, memo to self: test
2013/8/29 Tom Lane t...@sss.pgh.pa.us
So I was hacking away at supporting variadic aggregates (per an internal
request at Salesforce), and had it pretty much working, when I came across
this old comment in opr_sanity.sql:
-- Check that there are not aggregates with the same name and
Pavel Stehule pavel.steh...@gmail.com writes:
2013/8/29 Tom Lane t...@sss.pgh.pa.us
So the question I'm now wondering about is whether this consideration
makes variadic aggregates a bad idea all around, even if we don't have
any built-in ones. Is the risk of user confusion (in the use of
2013/8/29 Tom Lane t...@sss.pgh.pa.us
Pavel Stehule pavel.steh...@gmail.com writes:
2013/8/29 Tom Lane t...@sss.pgh.pa.us
So the question I'm now wondering about is whether this consideration
makes variadic aggregates a bad idea all around, even if we don't have
any built-in ones. Is
Tom,
On further reflection, what the policy was actually about was not that
we should forbid users from creating potentially-confusing aggregates
themselves, but only that we'd avoid having any *built in* aggregates with
this hazard. So maybe I'm overthinking this, and the correct reading is
Josh Berkus wrote:
Tom,
On further reflection, what the policy was actually about was not that
we should forbid users from creating potentially-confusing aggregates
themselves, but only that we'd avoid having any *built in* aggregates with
this hazard. So maybe I'm overthinking this,
On 2013-08-29 15:55:13 -0400, Tom Lane wrote:
So I was hacking away at supporting variadic aggregates (per an internal
request at Salesforce), and had it pretty much working, when I came across
this old comment in opr_sanity.sql:
-- Check that there are not aggregates with the same name and
Andres Freund and...@2ndquadrant.com writes:
On 2013-08-29 15:55:13 -0400, Tom Lane wrote:
For context see the thread starting here:
http://www.postgresql.org/message-id/aanlktikv5ok2ts8t6v+gsapte3n6tjq1jpphmzhg2...@mail.gmail.com
In that thread we agreed that this policy might be rather
On 2013-08-29 18:29:34 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-08-29 15:55:13 -0400, Tom Lane wrote:
For context see the thread starting here:
http://www.postgresql.org/message-id/aanlktikv5ok2ts8t6v+gsapte3n6tjq1jpphmzhg2...@mail.gmail.com
In that
On 08/29/2013 05:37 PM, Josh Berkus wrote:
Tom,
On further reflection, what the policy was actually about was not that
we should forbid users from creating potentially-confusing aggregates
themselves, but only that we'd avoid having any *built in* aggregates with
this hazard. So maybe I'm
2013/8/30 Andrew Dunstan and...@dunslane.net
On 08/29/2013 05:37 PM, Josh Berkus wrote:
Tom,
On further reflection, what the policy was actually about was not that
we should forbid users from creating potentially-confusing aggregates
themselves, but only that we'd avoid having any *built
18 matches
Mail list logo
