Based on this, I think we should just implement the TRUNCATE/DROP option
for the table, and avoid the idea of allowing non-logged operations on a
table that has any data we want recovered after a crash.
---
Simon Riggs wrote
Greets folks, [YABLP: Yet Another Bulk Loading Proposal]
The subject of this letter is referring to giving INSERT and COPY FROM STDIN
the ability to alter the destination of rows that violate any constraints named
in a user specified set.
I am seeking, as many others are or have, to improve the p
Tom Lane wrote:
> should be working towards a project policy that AC_CHECK_LIB calls
> shalt not use "main", but must name some symbol exported by the
> expected library. If we can't find out what symbols the library is
> expected to provide, it's time to dike it out.
I took a first swing at this
Mark Woodward wrote:
> >
> > On Feb 3, 2006, at 6:47 AM, Chris Campbell wrote:
> >
> >> On Feb 3, 2006, at 08:05, Mark Woodward wrote:
> >>
> >>> Using the "/etc/hosts" file or DNS to maintain host locations for
> >>> is a
> >>> fairly common and well known practice, but there is no such
> >>> mech
Mark Dilger wrote:
I've been thinking about this more, and now I don't see why this is an
issue. When the planner estimates how many rows will be returned from a
subquery that is being used within a join, it can't know which
"parameters" to use either. (Parameters being whatever conditions the
Josh Berkus wrote:
Tom,
What I'd like to do is implement the constant method for 8.2, and work
on doing the S() method later on. Does that make sense?
I'm not thrilled with putting in a stopgap that we will have to support
forever. The constant method is *clearly* inadequate for many (prob
>
> On Feb 3, 2006, at 6:47 AM, Chris Campbell wrote:
>
>> On Feb 3, 2006, at 08:05, Mark Woodward wrote:
>>
>>> Using the "/etc/hosts" file or DNS to maintain host locations for
>>> is a
>>> fairly common and well known practice, but there is no such
>>> mechanism for
>>> "ports." The problem now
> On Feb 3, 2006, at 12:43, Rick Gigger wrote:
>
>> If he had multiple ips couldn't he just make them all listen only
>> on one specific ip (instead of '*') and just use the default port?
>
> Yeah, but the main idea here is that you could use ipfw to forward
> connections *to other hosts* if you wa
Josh Berkus writes:
>> I'm not thrilled with putting in a stopgap that we will have to support
>> forever. The constant method is *clearly* inadequate for many (probably
>> most IMHO) practical cases. Where do you see it being of use?
> Well, mostly for the real-world use cases where I've run i
Tom,
> > What I'd like to do is implement the constant method for 8.2, and work
> > on doing the S() method later on. Does that make sense?
>
> I'm not thrilled with putting in a stopgap that we will have to support
> forever. The constant method is *clearly* inadequate for many (probably
> most
On Feb 3, 2006, at 11:21, Tom Lane wrote:
The SRF concept captures what you want a whole lot better. If the
implementation isn't up to snuff, we should improve it, not warp other
pieces of the system.
Point taken. The rewriting concept is what I'm after; if that can be
done pre-planning wit
Josh Berkus writes:
> What I'd like to do is implement the constant method for 8.2, and work on
> doing the S() method later on. Does that make sense?
I'm not thrilled with putting in a stopgap that we will have to support
forever. The constant method is *clearly* inadequate for many (probably
A nice workaraound because
EXECUTE 'select nextval(''test'')' INTO I;
doesnt work in 8.0 seems to be:
myid:=nextval('stvtrsid_seq'::TEXT);
This seems to work in every case.
Daniel
Jaime Casanova schrieb:
try this way:
CREATE OR REPLACE FUNCTION testseq() RETURNS void AS
$BODY$
BEGIN
E
Jeremy,
> The immediate use I thought of was being able to have what appeared to
> be multiple databases on the same server with different locale settings,
> which cannot be changed post-initdb.
Again, this is patching the symtoms instead of going after the cause. The
real issue you're trying
Josh Berkus wrote:
Mark,
This would only seem to work for trivial functions. Most functions that
I write are themselves dependent on underlying tables, and without any
idea how many rows are in the tables, and without any idea of the
statistical distribution of those rows, I can't really say
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
If we are talking about inserting the function definition into the
query as a subquery and then letting the parser treat it as a
subquery, then I see no reason to use either the existing function or
view subsystems. It sounds more like we
On Fri, 3 Feb 2006, Josh Berkus wrote:
> The feature you proposed is a way to make your idiosyncratic setup easier
> to manage, but doesn't apply to anyone else's problems on this list, so
> you're going to have a hard time drumming up enthusiasm.
I am somewhat reluctant to interject into this di
Mark,
> This would only seem to work for trivial functions. Most functions that
> I write are themselves dependent on underlying tables, and without any
> idea how many rows are in the tables, and without any idea of the
> statistical distribution of those rows, I can't really say anything like
>
Josh Berkus wrote:
Tom,
As for the dependency issue, one man's bug is another man's feature.
I think the fact that we don't track the internal dependencies of
functions is not all bad. We've certainly seen plenty of complaints
about how you can't easily change tables that a view is depending
Mark Dilger <[EMAIL PROTECTED]> writes:
> If we are talking about inserting the function definition into the
> query as a subquery and then letting the parser treat it as a
> subquery, then I see no reason to use either the existing function or
> view subsystems. It sounds more like we are discuss
Josh Berkus writes:
> BTW, the other thing that we're still TODOing on SRFs (as far as I know) is
> finding ways to change the row estimate for an SRF. It's still a flat
> 1000 in the code, which can cause a lot of bad query plans. I proposed a
> year ago that, as a first step, we allow the f
Tom Lane wrote:
Chris Campbell <[EMAIL PROTECTED]> writes:
True, as long as there's a hook to do the inlining/rewriting before
the query's planned. I guess we can see function calls at the parse
stage, check to see if they're SQL functions or not, grab the prosrc,
do the substitution, then
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > You'll still need to run the postmaster frmo pg_ctl to get the "run as
> > admin" part. The only part that could be moved is the Job Object for
> > management. And you're normally not going to need that one when you're
> > not runn
Tom,
> As for the dependency issue, one man's bug is another man's feature.
> I think the fact that we don't track the internal dependencies of
> functions is not all bad. We've certainly seen plenty of complaints
> about how you can't easily change tables that a view is depending on
> because th
Mark, all:
> > So your databases would listen on 5433, 5434, etc and the proxy would
> > listen on 5432 and route everything properly. If a particular cluster
> > is not up, the proxy could just error out the connection.
> >
> > Hmm, that'd be fun to write if I ever find the time...
>
> It is sim
Chris Campbell <[EMAIL PROTECTED]> writes:
> I'm fine with those limitations. I can confirm that all of my
> functions are not referencing tables that don't exist by doing a
> CREATE OR REPLACE FUNCTION to reload each function. A pg_dump/
> pg_restore would accomplish this, but it would be nic
On Feb 3, 2006, at 12:27, Tom Lane wrote:
I guess I can live without the dependancy tracking. I can always dump
and reload my database to re-parse all the functions. Maybe we could
have a RELOAD FUNCTION command that would just re-parse an existing
function, so I don't have to dump and reload?
On Feb 3, 2006, at 12:43, Rick Gigger wrote:
If he had multiple ips couldn't he just make them all listen only
on one specific ip (instead of '*') and just use the default port?
Yeah, but the main idea here is that you could use ipfw to forward
connections *to other hosts* if you wanted to.
On Feb 3, 2006, at 6:47 AM, Chris Campbell wrote:
On Feb 3, 2006, at 08:05, Mark Woodward wrote:
Using the "/etc/hosts" file or DNS to maintain host locations for
is a
fairly common and well known practice, but there is no such
mechanism for
"ports." The problem now becomes a code issue, n
Chris Campbell <[EMAIL PROTECTED]> writes:
> True, as long as there's a hook to do the inlining/rewriting before
> the query's planned. I guess we can see function calls at the parse
> stage, check to see if they're SQL functions or not, grab the prosrc,
> do the substitution, then re-parse?
[EMAIL PROTECTED] ("Mark Woodward") writes:
> The "port" aspect is troubling, it isn't really self
> documenting. The application isn't psql, the applications are custom
> code written in PHP and C/C++.
Nonsense. See /etc/services
> Using the "/etc/hosts" file or DNS to maintain host locations f
Chris Campbell <[EMAIL PROTECTED]> writes:
> I want to beef up rules versus beefing up functions.
Martijn didn't present a very convincing argument why this is a bad
idea, but I agree with him that it is. The problem to me is that a
"view with arguments" is fundamentally wrong --- a view is a vir
On Feb 3, 2006, at 10:25, Martijn van Oosterhout wrote:
Sure, for most procedural languages you can't do much. But we do do
syntax checking already and checking that the necessary functions
exist
can be considered part of that. It' s not terribly important though.
Dependancy tracking needs
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> It is similar to a proxy, yes, but that is just part of it. The setup and
> running of these systems should all be managed.
All that requires is some scripts that wrap pg_ctl and bring the right
instances up and down, perhaps with a web interface on t
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> You'll still need to run the postmaster frmo pg_ctl to get the "run as
> admin" part. The only part that could be moved is the Job Object for
> management. And you're normally not going to need that one when you're
> not running as a service. Maybe so
On Fri, Feb 03, 2006 at 09:18:51AM -0500, Chris Campbell wrote:
> So you think approaching it from the "beefing up functions" side
> would be better than the "beefing up views" side?
Well yes, I think you're underestimating the issues with trying to
extend views.
> >Technically a bug. We should
You'll still need to run the postmaster frmo pg_ctl to get the "run as
admin" part. The only part that could be moved is the Job Object for
management. And you're normally not going to need that one when you're
not running as a service. Maybe sometimes, but I doubt it's worth it. If
we could solve
Mark Woodward wrote:
> Oh come on, "misinformed?" is that really called for?
Claiming that all databases share the same system tables is misinformed,
with no judgement passed.
> The street database is typically generated and QAed in the lab. It is
> then uploaded to the server. It has many milli
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>
>> The point is, that I have been working with this sort of "use case" for
>> a
>> number of years, and being able to represent multiple physical databases
>> as one logical db server would make life easier. It was a brainstorm I
>> had
>> while I was
Salman Razzaq wrote:
> I found it difficult to use 'construct_md_array' as i want to
> construct an array with NULL elements included in it. How do i do that?.
Keep in mind that you can't do that in released versions (8.1 and
earlier); it's only possible in the current development bran
On Feb 3, 2006, at 08:50, Martijn van Oosterhout wrote:
Hmm, we actually do inline SQL functions under certain situations, but
only for "simple" queries (see inline_function in
optimizer/util/clauses.c). One approach would be to expand that
function to inline more complicated things.
* Better
Where are we on this patch?
I am thinking it should be in the most logical place, rather than in
pg_ctl. One call isn't a big deal, especially if you can run the
postmaster without using pg_ctl.
---
Magnus Hagander wrote:
On Fri, Feb 03, 2006 at 08:33:23AM -0500, Chris Campbell wrote:
> On Feb 3, 2006, at 02:09, Tino Wildenhain wrote:
>
> >Well if the view does not suit your needs, why dont you use an
> >set returnung function instead? Inside it you can do all the magic
> >you want and still use it similar to a tab
On Feb 3, 2006, at 08:05, Mark Woodward wrote:
Using the "/etc/hosts" file or DNS to maintain host locations for is a
fairly common and well known practice, but there is no such
mechanism for
"ports." The problem now becomes a code issue, not a system
administration
issue.
What if you ass
On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
> Using the "/etc/hosts" file or DNS to maintain host locations for is a
> fairly common and well known practice, but there is no such mechanism for
> "ports." The problem now becomes a code issue, not a system administration
> issue.
On Feb 3, 2006, at 02:09, Tino Wildenhain wrote:
Well if the view does not suit your needs, why dont you use an
set returnung function instead? Inside it you can do all the magic
you want and still use it similar to a table or view.
That's what I'm currently doing (as explained in the first me
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> The point is, that I have been working with this sort of "use case" for a
> number of years, and being able to represent multiple physical databases
> as one logical db server would make life easier. It was a brainstorm I had
> while I was setting this
> Mark Woodward schrieb:
> ...
>> Unless you can tell me how to insert live data and indexes to a cluster
>> without having to reload the data and recreate the indexes, then I
>> hardly
>> think I am "misinformed." The ad hominem attack wasn't nessisary.
>
> I see you had a usecase for something li
Dear Group Members,
Hi,
I found it difficult to use
'construct_md_array' as i want to construct an
array with NULL elements included in it. How do i do that?.
Thankyou.
My guess is that it was coded by someone different and needs to be made
consistent.
---
Kris Jurka wrote:
>
> Why is latin1 special in its conversion from unconvertible unicode data?
> Other latin character sets add a warn
Why is latin1 special in its conversion from unconvertible unicode data?
Other latin character sets add a warning, but latin1 errors out.
jurka=# create database utf8 with encoding ='utf8';
CREATE DATABASE
jurka=# \c utf8
You are now connected to database "utf8".
utf8=# create table t(a text);
Hi
I am modifying the source code. I want to look up some information
from some tables while parsing the queries. What functions I can use
to look up tables? btw I am using version 7.3. Thanks.
--
andrew
---(end of broadcast)---
TIP 4: Have you sea
Josh Berkus wrote:
Mark,
Even though they run on the same machine, run the same version of the
software, and are used by the same applications, they have NO
interoperability. For now, lets just accept that they need to be on
separate physical clusters because some need to be able to started and
53 matches
Mail list logo
