Ian Caulfield wrote:
2008/10/15 Ian Caulfield <[EMAIL PROTECTED]>:
I started to look at implementing array_agg by making the existing
intagg stuff more generic
... and here's what I've come up with.
Going through the commit fest listings, I think we can safely omit this
patch and work out a
I've been taking a look at this as well and came up with a slightly
different approach. The attached patch is intended to go in core (not
contrib) and uses some array-construction facilities that already
exist in core. I'm not sure which approach is better, so I'll throw
this out there with yours
2008/10/15 Ian Caulfield <[EMAIL PROTECTED]>:
> I started to look at implementing array_agg by making the existing
> intagg stuff more generic
... and here's what I've come up with.
I've currently implemented this as a contrib module to make it quicker
to develop/test.
The aggregate uses the sam
Greg Stark <[EMAIL PROTECTED]> writes:
> Come to think of it though... Do we require creators of new aggregates
> own the state transition function? If not we have a problem...
No, but they are required to have permission to call it. So you could
restrict the transition function to superusers i
2008/10/15 Greg Stark <[EMAIL PROTECTED]>:
> Sorry for top posting - darn phone...
>
> 1) as I mentioned when I reviewed the patch in commitfest I don't see the
> point of the manual memory management. Palloc/realloc has just the same kind
> of doubling behaviour behind the scenes anyways. Just cal
Sorry for top posting - darn phone...
1) as I mentioned when I reviewed the patch in commitfest I don't see
the point of the manual memory management. Palloc/realloc has just the
same kind of doubling behaviour behind the scenes anyways. Just call
realloc before adding every new element.
2008/10/14 Robert Treat <[EMAIL PROTECTED]>
>
> On Monday 13 October 2008 04:53:44 Markus Wanner wrote:
>
> > Having reviewed the last commit fest's intagg patch as well, I thought
> > we agreed that a more general functionality is wanted for core. But as
> > long as we don't have that, I'd like in
On Monday 13 October 2008 04:53:44 Markus Wanner wrote:
> Hi,
>
> Josh Berkus wrote:
> > So it sounds like intagg is still in use/development. But ... is it
> > more of an example, or is it useful as a type/function in production?
>
> We use it in production for quite remarkable speedups of operat
Hi,
Josh Berkus wrote:
> So it sounds like intagg is still in use/development. But ... is it
> more of an example, or is it useful as a type/function in production?
We use it in production for quite remarkable speedups of operations on
int4[].
Having reviewed the last commit fest's intagg patch
Gregory Stark wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>
>> D'Arcy J.M. Cain wrote:
>>> On Sun, 12 Oct 2008 12:57:58 +0300
>>> "Marko Kreen" <[EMAIL PROTECTED]> wrote:
On 10/11/08, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
> + if (!random_initialized)
> + {
>
Magnus Hagander <[EMAIL PROTECTED]> writes:
> D'Arcy J.M. Cain wrote:
>> On Sun, 12 Oct 2008 12:57:58 +0300
>> "Marko Kreen" <[EMAIL PROTECTED]> wrote:
>>> On 10/11/08, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
+ if (!random_initialized)
+ {
+ srandom((unsigned int) t
D'Arcy J.M. Cain wrote:
> On Sun, 12 Oct 2008 12:57:58 +0300
> "Marko Kreen" <[EMAIL PROTECTED]> wrote:
>> On 10/11/08, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
>>> + if (!random_initialized)
>>> + {
>>> + srandom((unsigned int) time(NULL));
>>> + random_initialized = true;
>
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Sun, 12 Oct 2008 12:57:58 +0300
> "Marko Kreen" <[EMAIL PROTECTED]> wrote:
>> This is bad idea, postgres already does srandom()
> Is that new? I added that to my local version at one time because I
> was getting the same salt every time I ran it
On Sun, Oct 12, 2008 at 10:41:21AM -0400, D'Arcy J.M. Cain wrote:
> > > + if ((result = (char *) palloc(16)) != NULL)
> > > + {
> > > + result[0] = ':';
> > > + strcpy(result + 1, password->password);
> > > + }
> >
> > AFAIK palloc() cannot return NULL?
>
> Really? My prog
On Sun, 12 Oct 2008 12:57:58 +0300
"Marko Kreen" <[EMAIL PROTECTED]> wrote:
> On 10/11/08, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
> > + if (!random_initialized)
> > + {
> > + srandom((unsigned int) time(NULL));
> > + random_initialized = true;
> > + }
>
> This is bad id
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> So it sounds like intagg is still in use/development. But ... is it
>> more of an example, or is it useful as a type/function in production?
Based on the patch submitted it's definitely in heavy production use.
--
Gregory Stark
EnterpriseDB
On 10/11/08, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
> No need. I have places to put it up. I would like to make the
> following changes for the CVS archives before it is removed though.
> Any objections?
>
> Index: chkpass.c
> =
Josh Berkus <[EMAIL PROTECTED]> writes:
> So it sounds like intagg is still in use/development. But ... is it
> more of an example, or is it useful as a type/function in production?
You're still asking the wrong list ...
regards, tom lane
--
Sent via pgsql-hackers mail
Josh Berkus wrote:
So it sounds like intagg is still in use/development. But ... is it
more of an example, or is it useful as a type/function in production?
Where I work we (and our customers) use it in our production systems.
At first glance it seems our reasons for using it are mostly
legac
On Sat, 11 Oct 2008 11:57:50 -0700
Josh Berkus <[EMAIL PROTECTED]> wrote:
> > However, if all it needs is a modern encryption scheme that's probably
> > an hour's work. The only reason that I haven't done so yet is because
> > I have no use case.
>
> Well, I had no use case either which is why I
All,
So it sounds like intagg is still in use/development. But ... is it
more of an example, or is it useful as a type/function in production?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
D'Arcy,
However, if all it needs is a modern encryption scheme that's probably
an hour's work. The only reason that I haven't done so yet is because
I have no use case.
Well, I had no use case either which is why I didn't propose updating
it. I can certainly see having chkpass live on pgFo
On Sat, 11 Oct 2008 16:07:31 +0200
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> D'Arcy J.M. Cain wrote:
> > However, if all it needs is a modern encryption scheme that's probably
> > an hour's work. The only reason that I haven't done so yet is because
> > I have no use case. If I am storing encr
D'Arcy J.M. Cain wrote:
> On Fri, 10 Oct 2008 16:28:29 -0700
> Josh Berkus <[EMAIL PROTECTED]> wrote:
>> It's that time again! Purging antiquated contrib modules.
>>
>> chkpass: this module is incomplete and does not implement all functions
>> it describes. It's not really even useful as an Exam
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
> > CREATE AGGREGATE array_accum (anyelement)
> >
> > CREATE OR REPLACE FUNCTION array_enum(anyarray)
>
> Have you actually tried these functions on large data sets? They're not in the
> same performance league
[EMAIL PROTECTED] wrote:
So it seems that intagg should rather live in a section "examples" than
in contrib?
Perhaps. Seems my old intagg use case from 8.1 is not really needed
anymore since it seems ANY got much smarter since then. Cool.
On Fri, 10 Oct 2008 16:28:29 -0700
Josh Berkus <[EMAIL PROTECTED]> wrote:
> It's that time again! Purging antiquated contrib modules.
>
> chkpass: this module is incomplete and does not implement all functions
> it describes. It's not really even useful as an Example since it uses
> crypt() an
>> If it's a bad way to do it, that's certainly an argument for keeping
>> (or maybe generalizing) intagg.
>
> There was actually a patch this past commitfest to *add* functionality to
> intagg. When I reviewed it I said it would make more sense to generalize it
> and integrate that functionality i
"Robert Haas" <[EMAIL PROTECTED]> writes:
> If it's a bad way to do it, that's certainly an argument for keeping
> (or maybe generalizing) intagg.
There was actually a patch this past commitfest to *add* functionality to
intagg. When I reviewed it I said it would make more sense to generalize it
>> CREATE AGGREGATE array_accum (anyelement)
>>
>> CREATE OR REPLACE FUNCTION array_enum(anyarray)
>
> Have you actually tried these functions on large data sets?
No. :-)
> They're not in the same performance league as intagg. Your array_accum is
> O(n^2)!
It's not "mine" - I copied it from th
"Robert Haas" <[EMAIL PROTECTED]> writes:
> CREATE AGGREGATE array_accum (anyelement)
>
> CREATE OR REPLACE FUNCTION array_enum(anyarray)
Have you actually tried these functions on large data sets? They're not in the
same performance league as intagg. Your array_accum is O(n^2)!
--
Gregory S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Oct 10, 2008 at 09:09:51PM -0700, Ron Mayer wrote:
> Josh Berkus wrote:
>> intagg: ... Has not been updated since 2001.
[...]
> I also like intagg, because it's kinda like a "hello world" for
> writing one kind of C extensions. I'm not say
Josh Berkus wrote:
intagg: ... Has not been updated since 2001.
Really? Just a couple years ago (2005) bugs we reported were
still getting fixed in it:
http://archives.postgresql.org/pgsql-bugs/2005-03/msg00202.php
http://archives.postgresql.org/pgsql-bugs/2005-04/msg00165.php
Here's one use
On Fri, 10 Oct 2008 16:28:29 -0700
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Folks,
>
> It's that time again! Purging antiquated contrib modules.
>
> chkpass: this module is incomplete and does not implement all
> functions it describes. It's not really even useful as an Example
> since it uses
> intagg: the aggregation function has been obsolete since 7.4 because
> standard array functionality supports the same. intagg has a nice
> equivalent for UNROLL, but it only works for arrays of INT, and only
> one-dimensional arrays. Has not been updated since 2001.
I think this one can be dro
Josh Berkus <[EMAIL PROTECTED]> writes:
> Any objections to dropping both of these?
You should ask on -general, not here, if you are trying to find out
whether the modules have any users.
I tend to agree that chkpass is of doubtful value, but I'm not so sure
about intagg. As you said yourself, w
Folks,
It's that time again! Purging antiquated contrib modules.
chkpass: this module is incomplete and does not implement all functions
it describes. It's not really even useful as an Example since it uses
crypt() and not any modern encryption. And Darcy hasn't touched it in 6
years.
in
37 matches
Mail list logo
