Hello
we talked about these features, but these functionality is solved with
UNNEST operator
http://farrago.sourceforge.net/design/CollectionTypes.html - so if you
like this functionality (I believe, so want it), please implement
UNNEST operator.
Regards
Pavel Stehule
Hello All,
in my last mail
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg114835.html
I have sent you a patch of pg_dump and pg_dumpall --role option support.
Nobody replied
or commented jet so now I send it again. The attached patch is the same
as the last one,
except it is
We discussed many times what on-line storage upgrade approach is best. Two of
them were still in the game. One is read all formats, write new only and
second is convert on read. The first one is general and complex solution which
needs lot of changes in the code. Second one is not so intrusive,
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
There's nothing in that functionality that contemplates
multi-dimensional arrays. Since we have multi-dimensional arrays,
oughtn't we provide the basic functions to deal with them?
array_ndims has got to be at least as useful as array_dims (which
returns an difficult-to-parse chunk of text).
Hello,
Postgres has configurations to log statements into server logs, but there
are few convenience ways to summarize the logs as a view. Some external
projects like pgFouine or PQA have the functionality, but they consume
much CPU resources and cannot summarize in real-time -- summarize-time
is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 11 oct. 08 à 01:50, Tom Lane a écrit :
Alvaro Herrera [EMAIL PROTECTED] writes:
It seems that the real way forward is to improve on that patch.
Yeah. If the schema-per-module answer were really a good answer,
we'd have done it before
To put that another way, there are other potential uses of this
function. For example, how would you suggest that someone do this?
CREATE TABLE foo (
id serial,
bar int[],
CHECK (array_ndims(bar) = 3)
);
You can hack something together, but it's not particularly nice.
...Robert
On
This crashes, apparently it tries to look up the result type on a NULL
planstate:
with recursive z(i) as (
select *
from t
union all
(with a(i) as (select * from z)
select * from a)
)
select * from z;
Incidentally, why are the parentheses required around 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.
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe the answer is to not throw away the first error message? But
presenting both messages could be confusing too.
Do we have the infrastructure to report more than one error? I thought
we didn't...
I was
* 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 Fri, Oct 10, 2008 at 09:10:50PM -0400, Tom Lane wrote:
Joshua Tolley [EMAIL PROTECTED] writes:
The new \ef psql command creates nicely usable CREATE OR REPLACE
FUNCTION ... text based on the function I tell it to edit, but the
text it creates *doesn't* include a final semicolon, so when
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
Gregory Stark [EMAIL PROTECTED] writes:
This crashes, apparently it tries to look up the result type on a NULL
planstate:
Tsk tsk, running CVS HEAD without Asserts?
It looks like things are getting initialized in the wrong order. Maybe
we need to attach the initplan lower down.
Hi,
Thanks for your information. Very appreciated!
When I convert the file as encoded as UTF-8, there will be no errors.
For my understanding, if the file is encoded as UTF-8, the first 3 bytes
will be efbbbf.
Maybe the cvs get the file only as ASCII format.
Now, the 3rdpart libxml and libxslt,
iihero wrote:
Hi,
Thanks for your information. Very appreciated!
When I convert the file as encoded as UTF-8, there will be no errors.
For my understanding, if the file is encoded as UTF-8, the first 3 bytes
will be efbbbf.
No, this is not necessary. That's the BOM (Byte Order Mark), but
Hiroshi's ossp-uuid build is the latest win32 build, and what we
shipped with 8.3.4.
On 10/11/08, Magnus Hagander [EMAIL PROTECTED] wrote:
iihero wrote:
Hi,
Thanks for your information. Very appreciated!
When I convert the file as encoded as UTF-8, there will be no errors.
For my
Magnus Hagander wrote:
This patch changes the options field of pg_hba.conf to take name/value
pairs instead of a fixed string. This makes it a lot nicer to deal with
auth methods that need more than one parameter, such as LDAP.
While at it, it also adds map support to kerberos, gssapi and
2008/10/11 Dimitri Fontaine [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 11 oct. 08 à 01:50, Tom Lane a écrit :
Alvaro Herrera [EMAIL PROTECTED] writes:
It seems that the real way forward is to improve on that patch.
Yeah. If the schema-per-module answer
2008/10/11 Robert Haas [EMAIL PROTECTED]:
There's nothing in that functionality that contemplates
multi-dimensional arrays. Since we have multi-dimensional arrays,
oughtn't we provide the basic functions to deal with them?
array_ndims has got to be at least as useful as array_dims (which
I'm afraid the patch was too huge, trying to send it again without attachment...
I made up my mind to scratch former window functions and redesigned
completely new execution model, based on the discussion with Heikki.
Attached is the v06 against HEAD today.
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:
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Would it be a worth it for us to implement a non-standard simple syntax
sugar on top of WITH RECURSIVE? Or, at least, something like
CONNECT_BY()?
The Oracle syntax only *looks* simple. When you start to study it
you realize that it's a
Tom,
Yeah. If the schema-per-module answer were really a good answer,
we'd have done it before now. But you need more infrastructure
than just a schema to get good things to happen. Aside from the
search-path-hell issue, a schema alone doesn't solve the problem
of persuading pg_dump to dump
Dimitri,
Am I correct in assuming, however, that you're not at all likely to
complete this for 8.4?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus [EMAIL PROTECTED] writes:
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Would it be a worth it for us to implement a non-standard simple syntax
sugar on top of WITH RECURSIVE? Or, at least, something like CONNECT_BY()?
The Oracle syntax only *looks* simple. When you
2008/10/11 Hitoshi Harada [EMAIL PROTECTED]
I'm afraid the patch was too huge, trying to send it again without
attachment...
I made up my mind to scratch former window functions and redesigned
completely new execution model, based on the discussion with Heikki.
Attached is the v06 against
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 11 oct. 08 à 21:10, Josh Berkus a écrit :
Am I correct in assuming, however, that you're not at all likely to
complete this for 8.4?
Not only that, but as I've yet to discover PostgreSQL internal code,
it would ask a lot of help and
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
I am drunk. I forgot cc to -hackers. The talk between me and Ian was like that.
2008/10/12 Hitoshi Harada [EMAIL PROTECTED]:
2008/10/12 Ian Caulfield [EMAIL PROTECTED]:
2008/10/11 Hitoshi Harada [EMAIL PROTECTED]:
2008/10/12 Ian Caulfield [EMAIL PROTECTED]:
2008/10/11 Hitoshi Harada [EMAIL
2008/10/11 Hitoshi Harada [EMAIL PROTECTED]:
I am drunk. I forgot cc to -hackers. The talk between me and Ian was like
that.
2008/10/12 Hitoshi Harada [EMAIL PROTECTED]:
2008/10/12 Ian Caulfield [EMAIL PROTECTED]:
2008/10/11 Hitoshi Harada [EMAIL PROTECTED]:
2008/10/12 Ian Caulfield [EMAIL
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe the answer is to not throw away the first error message? But
presenting both messages could be confusing too.
Do we have the infrastructure to report more than one error? I thought
we
Gregory Stark [EMAIL PROTECTED] writes:
This crashes, apparently it tries to look up the result type on a NULL
planstate:
with recursive z(i) as (
select *
from t
union all
(with a(i) as (select * from z)
select * from a)
)
select * from z;
Hmm ... I
Hi,
I believe it makes sense adding some more details to explain analyze output
like the number of pages read/written.
This will allow one to understand the workload the query puts on the server
making it easier to tune queries, choose the best indices, etc.
As far as I understand, this patch is
Howdy,
Any interest in adding a function like this to core?
Datum
pg_version(PG_FUNCTION_ARGS)
{
PG_RETURN_INT32(PG_VERSION_NUM);
}
That returns an integer, such as
try=# select pg_version();
pg_version
80304
(1 row)
I've whipped this up for pgtap, as it'll be useful
Vladimir Sitnikov [EMAIL PROTECTED] writes:
Hi,
I believe it makes sense adding some more details to explain analyze output
like the number of pages read/written. This will allow one to understand the
workload the query puts on the server making it easier to tune queries,
choose the best
Magnus Hagander [EMAIL PROTECTED] writes:
Here's an ugly attempt towards this. Though I'm unsure if we can change
the const on the PQerrorMessage parameter without messing with library
versions and such?
That's a bad idea in any case --- PQerrorMessage shouldn't be changing
the state of
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
This crashes, apparently it tries to look up the result type on a NULL
planstate:
with recursive z(i) as (
select *
from t
union all
(with a(i) as (select * from z)
select * from a)
The main problem I ran into was that the instrumentation nodes currently are
nested. That is, all the time for your children counts against you as well.
Is
that what we want for I/O costs?
As for me, I see nothing wrong with such costs model. I think it is good to
know stuff like the whole
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I'm inclined to prevent this case by forbidding recursive references
inside nested WITH clauses. Thoughts?
I'm a bit puzzled where the root of the problem lies here. Surely the nested
with clause is just equivalent
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
49 matches
Mail list logo
