Is it would be nice , if packages have been ;
1. Package level variables (Public variables)
is very hard for imlementation, and it's actually impossible. Needs large
changes in code
2. Package member level variables (Private variable)
I plan it, in every PL language
3. Public and
bruce wrote:
> bruce wrote:
> >
> > OK, seems this should be a separate application, not done in the TODO
> > list, and I am not willing to take on that additional workload.
>
> Let me add that anyone who has CVS commit access or wants to submit
> TODO patches can keep the TODO updated in this wa
Martijn van Oosterhout writes:
> My main problem is that selectivity is the wrong measurement. What
> users really want to be able to communicate is:
> 1. If you join tables a and b on x, the number of resulting rows will be
> the number of roows selected from b (since b.x id a foreign key
> refe
stark <[EMAIL PROTECTED]> writes:
> It seems odd to me that implicit casts are checked for when you call a
> function but not when you're implicitly calling a function via a cast. As a
> result there are a *lot* of redundant casts in our catalog, essentially n!
> casts for a domain with n types in
Tom Lane wrote:
The thing I object to about the "I want to decorate my queries with
planner hints" mindset is that it's coming at it from the wrong
direction. You should never be thinking in terms of "fix this one
query", because that just leads back into the same dead end that your
fix doesn't
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think we'd use the SCM module though.
Oddly enough if anything we could use the SCM module for
viewing/changest etc... I already have it regenerating itself over at
http://projects.commandprompt.com/public/pgsql
I've found that repository
It seems odd to me that implicit casts are checked for when you call a
function but not when you're implicitly calling a function via a cast. As a
result there are a *lot* of redundant casts in our catalog, essentially n!
casts for a domain with n types in it. So for example there are 138 casts
be
Csaba Nagy wrote:
Constantin,
What binding are you using ? We here use Java+JDBC, and we were able to
get stable query plans by forcing server side prepared statements (using
PGStatement#setPrepareThreshold with 1 as the threshold), where the
query is prepared without knowing the parameter value
On Tue, Aug 08, 2006, Tom Lane wrote:
> "Ralf S. Engelschall" <[EMAIL PROTECTED]> writes:
> > Hence I propose the patch below (applies to PostgreSQL 8.1.4) which
> > mimics the dlopen(3) and dlclose(3) behaviour of some Unix platforms
> > and resolves and calls _PG_init and _PG_fini functions of a
Joshua D. Drake wrote:
> >I don't think we'd use the SCM module though.
>
> Oddly enough if anything we could use the SCM module for
> viewing/changest etc... I already have it regenerating itself over at
> http://projects.commandprompt.com/public/pgsql
I've found that repository view to be br
Can you guys conceive of the thousands of hours of chat you guys are
racking upinstead of real hacking because you have an inadequate working
structure? This is by far the chattiest and least worthwhile listserv
in the bsd world. Bar none.
--
No virus found in this outgoing message.
Checke
I'd vote for a Trac site. I've found it to be a rather useful tool in
general, though a bit too simple-minded; integrated Wiki, a simple
bugtracker, and roadmap-style reports for people who cares about such
stuff.
I don't think we'd use the SCM module though.
Oddly enough if anything we could
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Josh Berkus"
Cc: "Tom Lane" <[EMAIL PROTECTED]>; "Pavel Stehule"
<[EMAIL PROTECTED]>; ;
Sent: Wednesday, August 09, 2006 1:49 AM
Subject: Re: [HACKERS] proposal for PL packages for 8.3.
Or we could just add local
Lukas Smith wrote:
> Josh Berkus wrote:
>
> >>OK, seems this should be a separate application, not done in the TODO
> >>list, and I am not willing to take on that additional workload.
> >
> >That's my feeling. But I think that we have enough people who are
> >interested to maintain it. If we
Josh Berkus wrote:
Bruce,
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
That's my feeling. But I think that we have enough people who are
interested to maintain it. If we don't, there was no point an
Josh Berkus wrote:
> Bruce,
>
> > I like the idea of a package being a schema. I imagine that a package
> > would put its own schema name first in the 'search_path' before
> > referencing an object. I think anything more complex is going to be too
> > hard to use.
> >
>
> Or we could just add
bruce wrote:
>
> OK, seems this should be a separate application, not done in the TODO
> list, and I am not willing to take on that additional workload.
Let me add that anyone who has CVS commit access or wants to submit
TODO patches can keep the TODO updated in this way.
---
Bruce,
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
That's my feeling. But I think that we have enough people who are
interested to maintain it. If we don't, there was no point anyway.
--Josh
-
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
---
Josh Berkus wrote:
> Bruce,
>
> > What happens now is that someone says they want to
Bruce,
I like the idea of a package being a schema. I imagine that a package
would put its own schema name first in the 'search_path' before
referencing an object. I think anything more complex is going to be too
hard to use.
Or we could just add local variables to schema and dispense with
Tom,
I'm confused. I thought the consensus was that we'd get package
functionality via SQL99 TYPEs, rather than by implementing
oracle-copycat syntax.
--Josh
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your d
Josh Berkus wrote:
Bruce,
What happens now is that someone says they want to work on X, and the
community tells them that Y might be working on it, and Y gives us a
status.
What happens now is:
A starts working on X.
3 months pass
B comes to hackers, spends hours reading the archives, doesn
On Aug 8, 2006, at 17:47 , Josh Berkus wrote:
What happens now is:
A starts working on X.
3 months pass
B comes to hackers, spends hours reading the archives, doesn't find
X (because they know it by a different name), comes to -hackers and
asks "Is anyone working on X?"
B waits for 2 week
Tom,
I concur with the other comment that plpgql is intended to mimic
Oracle PL/SQL, not SQL/PSM. If we try to follow two different leads
we are likely to find ourselves with a mess.
Well, the proposed functionality would be extremely useful in making
PL/pgSQL a more robust language. So ca
On Tuesday 08 August 2006 15:24, Markus Schiltknecht wrote:
>
> An API is always limiting.
Which is a good thing when you are not the one using it but the one committing
to support it. :-)
> I still feel that I would need ways too many hooks. Especially when you
> consider advanced replication f
On Tuesday 08 August 2006 17:44, Christopher Browne wrote:
> Most databases that are interesting to replicate are implemented in C
> or C++, thereby implying that a suitably "deep" API needs to be
> implemented in C.
>
> In the case of PostgresQL, at least, operating in Java means that you
> need t
Bruce,
What happens now is that someone says they want to work on X, and the
community tells them that Y might be working on it, and Y gives us a
status.
What happens now is:
A starts working on X.
3 months pass
B comes to hackers, spends hours reading the archives, doesn't find X
(because
If what we see in the todo is...
Implement hierarchical queries using ANSI "WITH"/recursive query
system | Someone | Under way | [some date six months ago]
... then those that are interested in seeing this go in can probably
guess that the effort has stalled in that nothing has been worth
comme
On Tue, Aug 08, 2006 at 04:14:45PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > ISTM theat the easiest way would be to introduce a sort of predicate
> > like so:
>
> > SELECT * FROM foo, bar WHERE pg_selectivity(foo.a = bar.a, 0.1);
>
> The one saving grace of Florian's proposal w
Martijn van Oosterhout writes:
> ISTM theat the easiest way would be to introduce a sort of predicate
> like so:
> SELECT * FROM foo, bar WHERE pg_selectivity(foo.a = bar.a, 0.1);
The one saving grace of Florian's proposal was that you could go hack
the statistics *without* changing your queries
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Pavel Stehule wrote:
>> I looked into SQL2003, and SQL2003 knows it (SQL/PSM):
>>
>> ::=
>>
>> |
>> ::=
>> SET
>> ::=
>> [ {
>> }... ]
>> ::=
>> SET
> The parentheses are apparently required for multiple variables, so in
> our case i
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Christopher Browne wrote:
>> >> Make postmater and postgres options distinct so the postmaster -o
>> >> option is no longer needed | Alvaro | Confirmed | 09/20/06
>> >>
>> >> Notice the sequence of events. I am not saying the specific statuses are
>> >>
Andrew Dunstan wrote:
> Stefan Kaltenbrunner wrote:
>> Tom Lane wrote:
>>
>>> Jeremy Drake <[EMAIL PROTECTED]> writes:
>>>
Plus if it is backported, I can enable 8.x builds on mongoose (my
x86 icc
buildfarm box).
>>> Please do --- I've applied the changes in 8.1 and
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Jeremy Drake <[EMAIL PROTECTED]> writes:
Plus if it is backported, I can enable 8.x builds on mongoose (my x86 icc
buildfarm box).
Please do --- I've applied the changes in 8.1 and 8.0 branches.
and leveret went green on both 8.
"Ralf S. Engelschall" <[EMAIL PROTECTED]> writes:
> Hence I propose the patch below (applies to PostgreSQL 8.1.4) which
> mimics the dlopen(3) and dlclose(3) behaviour of some Unix platforms
> and resolves and calls _PG_init and _PG_fini functions of an extension
> module right after/before the pg_
Bruce Momjian wrote:
A package would be a schema with its own variables,
private functions, and initialization functions
What are the intended scope and lifetime of package private variables?
This could be very cool and useful, but it could also be a m
Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
>> Plus if it is backported, I can enable 8.x builds on mongoose (my x86 icc
>> buildfarm box).
>
> Please do --- I've applied the changes in 8.1 and 8.0 branches.
and leveret went green on both 8.0 and 8.1 ...
Stefan
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> >> Are you saying that the package would effectively *be* a schema from the
> >> outside. That is, if I have package "foo" then I can't also have a schema
> >> "foo"?
>
> > Yes, because I don't need duplicity in function's names.
>
Christopher Browne wrote:
> >> Make postmater and postgres options distinct so the postmaster -o
> >> option is no longer needed | Alvaro | Confirmed | 09/20/06
> >>
> >> Notice the sequence of events. I am not saying the specific statuses are
> >> the way to go but it would give a simple way to
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian)
wrote:
> Joshua D. Drake wrote:
>> >>
>> >> For example:
>> >>
>> >> Make postmater and postgres options distinct so the postmaster -o
>> >> option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06
>> >
>> >
Markus Schiltknecht wrote:
>
> I'm questioning if a replication system can be written by only using
> triggers as hooks. AFAIK Slony-I uses triggers, so you can probably
> better comment on problems or limitations using triggers. For me a
> shared library with some hooks as C function calls seems a
Markus Schiltknecht wrote:
> Hi,
>
> Jose Orlando Pereira wrote:
>> Sorry, stuff was put twice in the zip file making it somewhat
>> confusing. It is in
>> postgresql-g-0.1/javasrc/GordaInterfaces/docs/gapi.pdf or directly on
>> the web site at http://gorda.di.uminho.pt/download/reports/gapi.pdf.
>
Hello Christopher,
Christopher Browne wrote:
Most databases that are interesting to replicate are implemented in C
or C++, thereby implying that a suitably "deep" API needs to be
implemented in C.
I generally agree with you. Although it's probably worth mentioning that
the API they propose ad
Joshua D. Drake wrote:
> >>
> >> For example:
> >>
> >> Make postmater and postgres options distinct so the postmaster -o
> >> option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06
> >
> >
> > We could do that, but once an item is done I don't see the point in
> > having the date an
In view of the other patch submitted to support init/fini functions for
shared libraries, I'm inclined to change this one to depend on that;
in particular it seems like we could eliminate the necessity for users
to specify the correct setup-function names. Thoughts?
I think that would
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> The attached patch adds support for loadable instrumentation plugins for
> procedural languages (as discussed at the anniversary summit). It also
> adds plugin support to the PL/pgSQL language handler.
In view of the other patch submitted to suppor
On 8/8/06, Joachim Wieland <[EMAIL PROTECTED]> wrote:
Merlin,
On Tue, Aug 08, 2006 at 12:32:05PM -0400, Merlin Moncure wrote:
> just fyi:
> did a cvs update around 12pm est today and am getting a make error:
> make -C connect all
> make: *** connect: No such file or directory. Stop.
> make: En
In the last exciting episode, [EMAIL PROTECTED] (Markus Schiltknecht) wrote:
> I'm operating a level deeper with Postgres-R and really enjoy the
> freedom I have with C. Having to write a hook or trigger for every
> change in the database systems seems a lot of work, which I tend to
> postpone unti
Merlin,
On Tue, Aug 08, 2006 at 12:32:05PM -0400, Merlin Moncure wrote:
> just fyi:
> did a cvs update around 12pm est today and am getting a make error:
> make -C connect all
> make: *** connect: No such file or directory. Stop.
> make: Entering an unknown directorymake: Leaving an unknown
> di
Martijn van Oosterhout wrote:
On Tue, Aug 08, 2006 at 01:55:35PM +0200, Florian G. Pflug wrote:
Hi
Since the discussion about how to force a specific plan has
come up, I though I'd post an idea I had for this a while ago.
It's not reall well though out yet, but anyway.
Image a query like "s
On 8/2/06, Michael Meskes <[EMAIL PROTECTED]> wrote:
I'm in the process of committing the first version of the ecpg
regression test suite to CVS. This is not exactly finished work, but it
shows OK on all test on my machine and on Joachim's machine. The tests
need to be tweaked some before it's fi
For example:
Make postmater and postgres options distinct so the postmaster -o
option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06
We could do that, but once an item is done I don't see the point in
having the date and person's name. You are right that is clearly a
different
On Tue, Aug 08, 2006 at 01:55:35PM +0200, Florian G. Pflug wrote:
> Hi
>
> Since the discussion about how to force a specific plan has
> come up, I though I'd post an idea I had for this a while ago.
> It's not reall well though out yet, but anyway.
> Image a query like "select ... from t1 join
On Tue, Aug 08, 2006 at 09:09:17AM -0400, Tom Lane wrote:
> * The vulnerability to using a previously installed ecpglib exists in
> our default Linux configuration as well as HPUX.
On my linux box the libs get built with -rpath as well and I think that
there's no portable way to remove it once it
On 8/8/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Are we intending to support SQL/PSM with PL/pgSQL?
I hope not. While PL/pgSQL and SQL/PSM share some similarities, they
should be totally separate. IIRC, EnterpriseDB had tried to sponsor
someone to write SQL/PSM support for PostgreSQL a li
Andrew Dunstan wrote:
> Pavel Stehule wrote:
> >I looked into SQL2003, and SQL2003 knows it (SQL/PSM):
> > [grammar productions]
>
> The parentheses are apparently required for multiple variables, so in
> our case it might look like this:
>
> (a,b,c) := foo(bar);
>
> That might overcome the ob
Pavel Stehule wrote:
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In
From: Tom Lane <[EMAIL PROTECTED]>
To: "Pavel Stehule" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], dev@archonet.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal for PL packages for 8.3. Date: Tue, 08 Aug
2006 08:18:42 -0400
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I unl
If this feature I'm proposing already exists, sorry for the waste of bandwidth,
and could someone please point me to it? :)
What if there were a mode that told postgres to do an exhaustive search (or if
not exhaustive, then much more extensive search) of all plans (or many plans),
trying each
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In any case, I had some
Josh Berkus napsal(a):
Zdenek,
However what happened? I think that following scenarios occurred.
Postmaster listen only in one process and there are many clients run
really parallel. T2000 server has 32 threads ( 8 core and each has 4
threads). These clients generate more TCP/IP request at one
Bruce Momjian wrote:
I am saying other people can try a new system, but I don't have time to
try something different when no evidence has been given that it is
better (just different).
Ok, not sure if I am in a position to "call shots" like I am about to,
but here it goes:
Could everybody who
Andrew Dunstan wrote:
> > My big point is that we should choose a system that would have had a
> > better chance of completing features than what we have used in the past,
> > and no one has suggested one.
> >
> > It is just like the bug tracker issue. Many think we need a bugtracker,
> > but when
Hi,
Jose Orlando Pereira wrote:
Sorry, stuff was put twice in the zip file making it somewhat confusing. It is
in postgresql-g-0.1/javasrc/GordaInterfaces/docs/gapi.pdf or directly on the
web site at http://gorda.di.uminho.pt/download/reports/gapi.pdf.
Thank you. I've just had a quick glance
Bruce Momjian wrote:
Or try a new system, and I will keep doing what I do, and we can see
which system works best.
Excellent idea. We don't have to have a one size fits all set of
procedures anyway - in fact I think it might be a mistake. Maybe we
should select a few major features
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > I know about the same as the community members who pay attention to
> > postings. What I do is to act on that information by contacting
> > developers and asking them to complete their work for feature freeze.
> > Many of my conversations are not ap
I wrote:
> With "make install" before "make check", I get a
> clean pass with this morning's CVS tip (using gcc ... will try HP's
> cc in a bit).
Further results:
* The vulnerability to using a previously installed ecpglib exists in
our default Linux configuration as well as HPUX.
* Still fails
Bruce Momjian wrote:
I know about the same as the community members who pay attention to
postings. What I do is to act on that information by contacting
developers and asking them to complete their work for feature freeze.
Many of my conversations are not appropriate for the public, which is
why
Michael Meskes <[EMAIL PROTECTED]> writes:
> We changed some things that should remove most of the differences you
> had.
> Two other diffs looked like you had an older version of ecpglib running.
> Could that be?
Bingo --- I had been doing "make clean", "make all", "make check".
It seems this
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I unlike concept of nested schemats or packages nested in schema. I
don't
> see reason for it. About implementation.. package is more special kind
of
> function for me. But relation between package and function I can create
via
> dot notation in
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I unlike concept of nested schemats or packages nested in schema. I don't
> see reason for it. About implementation.. package is more special kind of
> function for me. But relation between package and function I can create via
> dot notation in fun
We changed some things that should remove most of the differences you
had.
Two other diffs looked like you had an older version of ecpglib running. Could
that be?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: mi
Hi
Since the discussion about how to force a specific plan has
come up, I though I'd post an idea I had for this a while ago.
It's not reall well though out yet, but anyway.
When the topic of optimizer hints comes up, people often suggest
that there should be a way to force postgres to use a cer
Markus Schiltknecht wrote:
> Hi,
>
> José Orlando Pereira wrote:
>> I would argue that people haven't been able to build production-grade
>> multi-master replication, in part, due to the barrier of not having a
>> "standard" database-agnostic API. :-)
>>
>> In fact, the problem is not the lack of a
On Tue, 2006-08-08 at 12:36, Constantin Teodorescu wrote:
> We have tried PGStatement#setPrepareThreshold with 1 as the threshold
> but it's not a good solution.
> Actually is worst. Considering that you have 5 different query plans,
> you are selecting approx. random one of them, not taking into
Constantin,
What binding are you using ? We here use Java+JDBC, and we were able to
get stable query plans by forcing server side prepared statements (using
PGStatement#setPrepareThreshold with 1 as the threshold), where the
query is prepared without knowing the parameter values. This can
backfire
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap algorithmns, and if
the cost exceeds a cer
77 matches
Mail list logo
