Alvaro Herrera 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 that.) It's true that
pre-
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 subscriptio
2013/8/30 David Johnston
> 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
> >> happ
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
David Johnston 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 standard,
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
> >>
Tom Lane-2 wrote
> Pavel Stehule <
> pavel.stehule@
> > 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,
Pavel Stehule 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 well and simply. If
2013/8/30 Andrew Dunstan
>
> 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
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 o
On 2013-08-29 18:29:34 -0400, Tom Lane wrote:
> Andres Freund 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 agree
Andres Freund 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 squishy,
>> but we
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
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 overthink
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 readi
2013/8/29 Tom Lane
> Pavel Stehule writes:
> > 2013/8/29 Tom Lane
> >> 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 their
>
Pavel Stehule writes:
> 2013/8/29 Tom Lane
>> 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 their
>> own aggregate) sufficient reas
2013/8/29 Tom Lane
> 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 different
> -- numbers
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 different
-- numbers of arguments. While not techni
19 matches
Mail list logo
