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
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
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);
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
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.
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 like pg_diff
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 sort of
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
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 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 table or
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 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
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
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 sort
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 millions
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 be
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 top of
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
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 sometimes,
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
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 virtual
[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 for is
a
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?
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, not
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
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?
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 nice to
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 similar to a
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 the
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 running as a
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
Josh Berkus josh@agliodbs.com 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,
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 discussing a
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,
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
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
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
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
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 to
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
Josh Berkus josh@agliodbs.com 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
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
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 IMHO)
Josh Berkus josh@agliodbs.com 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
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, not
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
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
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
mechanism for
ports. The
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 and
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
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
52 matches
Mail list logo
