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 an
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 intagg to
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/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 call
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 if
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 same
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
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 operations on
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
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
===
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 idea, postgres
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 program will simply come
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.
Quite a
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;
+ }
This is bad
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) time(NULL));
+
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)
+ {
+ srandom((unsigned int)
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 Stark
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 the official
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
and
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 into the
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() and not
[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.
* 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 as intagg.
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 Example since
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 encrypted
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
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:
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 didn't
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
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 mailing
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, we
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
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 crypt()
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
-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 saying it
36 matches
Mail list logo
