"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_nu
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
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 eq
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
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)
>>
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
"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 th
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
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
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;
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?
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
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
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
-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 effo
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
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* simp
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
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 a
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
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
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.
http://umitanuki.net/pgsql/wfv06/design
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
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 schem
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 an
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 m
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
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,
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.
> Incident
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
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 semicol
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
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...
[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
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 s
>> 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
-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 no
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
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).
...R
"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
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 intrusi
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
48 matches
Mail list logo
