On Thu, 2002-08-01 at 17:14, Bruce Momjian wrote:
>
> J.R needs comments on this. PITR has problems because local relations
> aren't logged to WAL. Suggestions?
>
I'm sorry if it wasn't clear. The issue is not that local relations
aren't logged to WAL, they are. The issue is that you can't che
Ok, here are some crude benchmarks to attempt to measure the effect of
changing FUNC_MAX_ARGS. The benchmark script executed:
CREATE FUNCTION test_func(int, int, int, int, int, int, int, int)
RETURNS INTEGER AS 'SELECT $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8'
LANGUAGE 'sql' VOLATILE;
Followed by 3
Thanks. That looks acceptable to me, and a good test.
---
Neil Conway wrote:
> Ok, here are some crude benchmarks to attempt to measure the effect of
> changing FUNC_MAX_ARGS. The benchmark script executed:
>
> CREATE FUN
On Thursday 01 August 2002 05:22 pm, Bruce Momjian wrote:
> Lamar Owen wrote:
> > It's already in CPAN. A link to CPAN should suffice, IMHO.
> > I also thought we were discussing trimming the tree; and that was a good
> > feeling.
> Lamar, you said earlier today:
> > And the sooner our very old
It is possible I may be off line intermittently during the next few
weeks. I am moving to a new house _and_ my ISP is switching ADSL
providers at the same time.
This may effect my email account and web pages. I have a secondary mail
host so I will not lose any mail, but I am not sure I can keep
OK, we need all the interfaces to properly handle schemas within the
next month. However, we don't have psql working properly yet. Once we
get psql working, we can show examples of the changes we made and the
other interfaces can use that as a model.
Is anyone working on schema fixes for psql?
Bruce Momjian wrote:
> Functions Returning Sets - done?
The basic capability is done, but a number of supporting capabilities
remain. These are the ones I hope to have done for 7.3:
- PL/pgSQL table function support: not started, but I may get help with
this.
- anonymous composite types: pat
On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote:
>
> Who cares? Those that need a C++ interface will know where to find it,
> and will report bugs that they have ... why should it be tested on every
> platform when we *might* only have those on the Linux platform using it?
Wel
On Fri, 2 Aug 2002, jtv wrote:
> Looking at it that way, it seems to me that the proper approach is to
> cut out all interfaces that don't talk to the backend themselves--e.g.
> the ones that build on top of libpq, like libpq++ and libpqxx do.
This is what my opinion is ... what I'm setting up r
> No, there isn't (for example, pg_stat_backend_id() versus
> current_schema() -- or pg_get_viewdef() versus obj_description() ).
> Now that we have table functions, we might be using more built-in
> functions to provide information to the user -- so there will be
> an increasing need for some kin
Just use $libdir...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Ramsey
> Sent: Friday, 2 August 2002 4:01 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Module Portability
>
>
> All this talk of modularity reminds me of a pet peev
On 1 Aug 2002, Greg Copeland wrote:
> For some reason,
> many of the developers are under the impression that even if code is
> never touched, it has a very high level of effort to keep it in the code
> base. That is, of course, completely untrue.
Where does this "of course" come from? I've bee
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can rename backend_pid if people want. I just made it consistent
> with the other functions in that docs area. Comments?
I'd go for pg_backend_pid, I think. It's not an SQL standard function
and certainly never will be, so some sort of prefix seem
Greg Copeland <[EMAIL PROTECTED]> writes:
> I seem to find this argument a lot on the list here. For some reason,
> many of the developers are under the impression that even if code is
> never touched, it has a very high level of effort to keep it in the code
> base. That is, of course, complete
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>> Ummm ... stupid question, but can we even bring this into the 'core'?
>>
>> You may distribute under the terms of either the GNU General Public
>> License or the Artistic License, as specified in the Perl README file.
> Artis
...
> Perhaps a more relevant question is why are we cluttering the namespace
> with any such function at all? What's the use case for it? We've
> gotten along fine without one so far, and I don't really think that we
> *ought* to be exposing random bits of internal implementation details
> at t
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> I am working on a way to do this with a signal, using holdoffs around
> calls into the storage-manager and VFS layers to prevent re-entrant
> calls. The local buffer manager is simple enough that it should be
> possible to flush them from within a signal
> > With FUNC_MAX_ARGS=16:
> > (average = 28.6 seconds)
> > With FUNC_MAX_ARGS=32:
> > (average = 29.15 seconds)
That is almost a 2 percent cost. Shall we challenge someone to get us
back 2 percent from somewhere before the 7.3 release? Optimizing a hot
spot might do it...
On Fri, 2 Aug 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Marc G. Fournier wrote:
> >> Ummm ... stupid question, but can we even bring this into the 'core'?
> >>
> >> You may distribute under the terms of either the GNU General Public
> >> License or the Artistic License
On Fri, 2 Aug 2002, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > I seem to find this argument a lot on the list here. For some reason,
> > many of the developers are under the impression that even if code is
> > never touched, it has a very high level of effort to keep it in t
On Thu, 1 Aug 2002, Thomas Lockhart wrote:
> > > With FUNC_MAX_ARGS=16:
> > > (average = 28.6 seconds)
> > > With FUNC_MAX_ARGS=32:
> > > (average = 29.15 seconds)
>
> That is almost a 2 percent cost. Shall we challenge someone to get us
> back 2 percent from somewhere before the 7.3 release? Opt
On Fri, 2 Aug 2002, Marc G. Fournier wrote:
> Isn't inheritance kinda one of those things that is required in order to
> be consider ourselves ORBDMS, which we do classify our selves as being?
Well, it depends on what you call an ORDBMS. By the standards of
Date and Darwen in _The Third Manifest
101 - 122 of 122 matches
Mail list logo
