David E. Wheeler [EMAIL PROTECTED] writes:
Any interest in adding a function like this to core?
No, because it's already there: see show server_version_num.
(It's probably worth noting that none of our existing clients that would
have any use for this information look at server_version_num,
I confirmed this on Oracle:
select last_value(id) over (order by id) as last_id, id from foo;
LAST_ID ID
--- --
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
So when you specify ORDER BY clause on window definition, the frame
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
If we were to flatten it to a plain select * from z then maybe things
would work all right, but the present implementation treats both WITH
clauses as equally requiring single evaluation.
Surely it should be a single evaluation for each time that branch of
the upper WITH is recursively
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
===
so I wonder, quite few times ppl asked me about my-word database TOP %
PERCENT (and I guess ms-word db has it too).
Now that postgres has limit(subselect) - postgresql can do the same
thing. But, using a count(*) in subselects isn't very efficient. The
backend gets information from limit X,
2008/10/12 Grzegorz Jaskiewicz [EMAIL PROTECTED]:
so I wonder, quite few times ppl asked me about my-word database TOP %
PERCENT (and I guess ms-word db has it too).
Now that postgres has limit(subselect) - postgresql can do the same thing.
But, using a count(*) in subselects isn't very
that's a shame.
I figure, with the WITH ... AS .. you can kind of speed up counts,
just by doing it once - now. But still, it would be great to be able
to use PERCENT, against estimate.
After all, imagine a table FOO with 5 rows, and something like this:
WITH c AS (select count(*)/4 as n
Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have toast
chunk size more flexible.
Attached patch add three new columns into pg_class
relblocksize - which is always BLCKSZ. I put it there for fullness, but i could
be use in future development to specify different
I wonder if this could be implemented using the window-function
infrastructure...
...Robert
On Sun, Oct 12, 2008 at 9:07 AM, Grzegorz Jaskiewicz
[EMAIL PROTECTED] wrote:
that's a shame.
I figure, with the WITH ... AS .. you can kind of speed up counts, just by
doing it once - now. But still,
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
2008/10/12 Robert Haas [EMAIL PROTECTED]:
I wonder if this could be implemented using the window-function
infrastructure...
Yeah, actually window functions I am working now has percent_rank() or
something he wants. That is better than WITH clauses but still we must
see the last row before
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));
+
Hi,
It might be relevant for the whole discussion about inclusion of some form of
row level permissions, whatever based on, that there exist heaps of (in my
eyes conflicting) patents about row level permissions for relational
databases. I don't have any real clue about patent issues, but I
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)
On Oct 11, 2008, at 19:57, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Any interest in adding a function like this to core?
No, because it's already there: see show server_version_num.
(It's probably worth noting that none of our existing clients that
would
have any use
David E. Wheeler wrote:
On Oct 11, 2008, at 19:57, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Any interest in adding a function like this to core?
No, because it's already there: see show server_version_num.
(It's probably worth noting that none of our existing clients
On Oct 12, 2008, at 11:21, Magnus Hagander wrote:
Yeah, but I want to use it in WHERE clauses or CASE statements. I'm
fine
to just include it in pgtap, though.
You could do:
select setting from pg_settings where name='server_version_num';
(wrapped in the appropriate subselect to use it in
David E. Wheeler [EMAIL PROTECTED] writes:
On Oct 11, 2008, at 19:57, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Any interest in adding a function like this to core?
No, because it's already there: see show server_version_num.
Yeah, but I want to use it in WHERE clauses or
On Oct 12, 2008, at 12:42, Tom Lane wrote:
Yeah, but I want to use it in WHERE clauses or CASE statements.
current_setting('server_version_num')
Hrm. That's nice. I don't suppose there's any way to get something
like that in 8.1 and earlier? I was going to fake it in the .c file.
David E. Wheeler [EMAIL PROTECTED] writes:
On Oct 12, 2008, at 12:42, Tom Lane wrote:
current_setting('server_version_num')
Hrm. That's nice. I don't suppose there's any way to get something
like that in 8.1 and earlier? I was going to fake it in the .c file.
You'd have to parse the result
Hi,
Released new sets:
http://people.planetpostgresql.org/devrim/index.php?/archives/124-New-shapshot-RPMs-Oct-11-2008-are-ready-for-testing.html
Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
On Oct 12, 2008, at 14:11, Tom Lane wrote:
You'd have to parse the result of version().
As I figured. This is what I'm trying:
pg_version_num(PG_FUNCTION_ARGS)
{
#ifdef PG_VERSION_NUM
PG_RETURN_INT32(PG_VERSION_NUM);
#else
/* Code borrowed from dumputils.c. */
int
On 2008-10-12, at 16:22, Hitoshi Harada wrote:
2008/10/12 Robert Haas [EMAIL PROTECTED]:
I wonder if this could be implemented using the window-function
infrastructure...
Yeah, actually window functions I am working now has percent_rank() or
something he wants. That is better than WITH
OK, I found a real solution: we can fix nodeWorktablescan.c so that the
order of initialization doesn't matter, by postponing the steps that
need information from the RecursiveUnion node until the first exec call
for the worktable node.
Although nodeCtescan is making a similar assumption about
Zdenek Kotala [EMAIL PROTECTED] writes:
Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have
toast
chunk size more flexible.
Attached patch add three new columns into pg_class
relblocksize - which is always BLCKSZ. I put it there for fullness, but i
could
be use
Zdenek Kotala [EMAIL PROTECTED] wrote:
Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have
toast
chunk size more flexible.
I agree that flexible toast threshold is useful, but I have
several questions in your implementations.
relblocksize - which is always BLCKSZ.
Vladimir Sitnikov [EMAIL PROTECTED] wrote:
I've tried to use ReadBufferCount and friends from
storage\buffer\buf_init.c, however it is showing zeroes for some unknown yet
reason. Hope, there is no fundamental problem behind.
I think those vairables are hard to use and have no reliability
for
So somehow I got dragooned into speaking at the Pittsburgh Perl Workshop
(which is held only a couple miles from where I live, so it was hard to
say no). A portion of what I had to say was that CPAN seemed to be a
lot better-run than pgfoundry.
So ... I couldn't help noticing that the consensus
Tom Lane wrote:
So ... I couldn't help noticing that the consensus among the Perl guys
seemed to be that 90% of what is on CPAN is unmaintained crap.
(They agree however that the other 10% is what makes it worth doing; and
furthermore that you can't easily tell which fraction any new project
2008/10/13 Grzegorz Jaskiewicz [EMAIL PROTECTED]:
On 2008-10-12, at 16:22, Hitoshi Harada wrote:
2008/10/12 Robert Haas [EMAIL PROTECTED]:
I wonder if this could be implemented using the window-function
infrastructure...
Yeah, actually window functions I am working now has percent_rank()
34 matches
Mail list logo
