Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Is someone taking care about the fact that the pgdb.py shipped with
> 7.4.1 is the wrong version?
There is no pgdb.py in the core PG 7.4.* releases. I suppose you
are talking about a packaging error in the RPM distribution. Lamar Owen
would be the ma
Doug McNaught <[EMAIL PROTECTED]> writes:
> "Ben" <[EMAIL PROTECTED]> writes:
>> Doug, thanks - do you know if the system catalogs retain the same
>> abilities in 7.4? So that if I implement this, will it still work later? I
>> don't mind "hairy", but "temporary" is a concern, at least.
> The syst
[EMAIL PROTECTED] (harjan) writes:
> cannot extend "table name" input/output error check free disk space
> The hard disk has about 1 gb free space.
> Pls advise.
The "check free disk space" bit is just a hint, which is not very
relevant in this case. The critical part of that message is the
kern
Couple of ways to do it. One is to use the hierarchical query patch
that mimics Oracle's CONNECT BY
syntax at
http://www.brasileiro.net/postgres/cookbook/view-one-recipe.adp?
recipe_id=19490.
Another way is to use a nested set model, described at
http://www.geocrawler.com/archives/3/6/2001/
Is someone taking care about the fact that the pgdb.py shipped with
7.4.1 is the wrong version? What bail me out is the fact that the
version pgdb.py shipped with 7.4.1 is a version *pre 7.3*; we
add the same "bug" with the 7.3 and was not solved until the 7.3.2
distribution:
http://archives.postgr
"Ben" <[EMAIL PROTECTED]> writes:
> On Sat, 31 Jan 2004 23:41:54 -0500, Doug McNaught wrote:
>
>> For 7.3, the info you need is available in the system catalogs, which
>> have a somewhat hairier layout than the SQL-standard information_schema.
>
> Doug, thanks - do you know if the system catalogs
I have a table with these columns:
id, node, parent_node_id
The top-most nodes would have a parent_node_id of
NULL. Is it possible to get a node, and all its parent
nodes, in a single query?
For example, a node might be:
books > computers > databases > oss > postgres
and the rows fetched would
On Mon, Feb 02, 2004 at 06:03:46AM -0800, Remi wrote:
> To do this, we got a
> postgresql script, placed it in the init.d folder with all the other
> service shell scripts, and then went into services, add service, and
> typed postgres. The specific error received is:
>
> env: /etc/init.d/postgre
Would you attach your startup script?
2 other questions?
1. Are all the binaries you are calling using the full paths?
2. Are you calling the pg_ctl as user postgres(or other user) (i.e. su -
postgres -c 'pg_ctl .'
Quoting Remi <[EMAIL PROTECTED]>:
> Hello,
>
> I've installed redhat
On Sat, 31 Jan 2004 23:41:54 -0500, Doug McNaught wrote:
> For 7.3, the info you need is available in the system catalogs, which
> have a somewhat hairier layout than the SQL-standard information_schema.
Doug, thanks - do you know if the system catalogs retain the same
abilities in 7.4? So that i
Michal Hlavac <[EMAIL PROTECTED]> writes:
> groups[] := tmpi;
> returns error: syntax error at or near "["
This is supported in PG 7.4 (although you do need to provide a subscript
expression ...)
regards, tom lane
---(end of broadcast)
Richard Schilling <[EMAIL PROTECTED]> writes:
> Looking at your query, I notice that the longer query happens when you
> search on b.zcustnum=30538 while the LEFT OUTER JOIN remains the same.
> It could be that when testing a.zcustnum=30530 the server can short
> circuit the logic - it only has
I need to return a row of data from a function. I've been looking the the HTML
docs and have found nothing of value. If I try to return a variable of type
RECORD, I get the following error:
NOTICE: plpgsql: ERROR during compile of last_log near line 0
ERROR: fmgr_info: function 0: cache lookup
uom := (select uom from prodclass where code = prod_class) ;
Now I want to know why this syntax even compiles!?
What does this mean in plpgsql and where can I find a discussionin the
documentation?
Rick
Tom Lane wrote:
"Frank Millman" <[EMAIL PROTECTED]> writes:
uom := (select uo
Hello,
I'm setting up a PostgreSQL installation accessible by many different
users. The layout is:
- all users connect to the same database
- every user has its own schema, no write access to the public schema
- by default no additional privileges for the users
Thus, a use
On Mon, 2004-02-02 at 22:11, Alvaro Herrera wrote:
> On Mon, Feb 02, 2004 at 04:22:29PM +1100, Stephen Robert Norris wrote:
> > On Fri, 2004-01-30 at 13:04, Alvaro Herrera wrote:
> > > On Thu, Jan 29, 2004 at 08:50:47PM -0500, Manuel Tejada wrote:
> > >
> > > > By the way, what does mean RHEL3?
>
Kris Jurka said:
> If you need "english" sorting like "en_GB" then that is the best option,
> but if you just need regular sorting the C locale might be better. It is
> sometimes confusing how en_US (I assume GB is similar) sorts strings with
> spaces and punctuation and so on.
If I switch from "
On Mon, Feb 02, 2004 at 04:22:29PM +1100, Stephen Robert Norris wrote:
> On Fri, 2004-01-30 at 13:04, Alvaro Herrera wrote:
> > On Thu, Jan 29, 2004 at 08:50:47PM -0500, Manuel Tejada wrote:
> >
> > > By the way, what does mean RHEL3?
> >
> > "Red Hat Entreprise Linux", a commercial Linux distrib
On Mon, 2 Feb 2004, John Sidney-Woollett wrote:
> Kris, thanks for you feedback. Can you give me any further info on the
> questions below?
>
> Kris Jurka said:
> >> 3) If I want accented characters to sort correctly, must I select
> >> UNICODE
> >> (or the appropriate ISO 8859 char set) over SQ
Kris, thanks for you feedback. Can you give me any further info on the
questions below?
Kris Jurka said:
>> 3) If I want accented characters to sort correctly, must I select
>> UNICODE
>> (or the appropriate ISO 8859 char set) over SQL_ASCII?
>
> You are confusing encoding with locale. Locales de
Merrall, Graeme wrote:
I don't think there's an easy way to do this but I thought I better ask just in case. I'm trying to come up with a way to search across a number of databases without resorting to lots of horrible scripts. In one database I have a lot of news stories from our news provider wh
Ahh! Thanks Kris! That works!
-- Csaba
> -Original Message-
> From: Kris Jurka [mailto:[EMAIL PROTECTED]
> Sent: 2004. február 2. 10:14
> To: Együd Csaba
> Cc: [EMAIL PROTECTED] (E-mail)
> Subject: Re: [GENERAL] How to kick out automatically stuck in queries
>
>
>
>
> On Mon, 2 Feb 2004, [
On Mon, 2 Feb 2004, [iso-8859-2] Együd Csaba wrote:
> Hi All,
> I'm wonder if there is any possibility to kick out automatically stuck in
> queries after say 10 minutes or so?
> I mean some kind of queries which calls eg. buggy functions with dead loops
> or something similar.
> Time to time I f
DECLARE
groups integer[];
tmp RECORD;
tmpi integer;
BEGIN
FOR tmp IN SELECT i_group_id FROM l_group_to_user WHERE i_user_id =
$1 LOOP
SELECT i_group_id INTO tmpi FROM s_group WHERE i_group_id =
tmp.i_group_id;
groups[] := tmpi;
RETURN NEXT tmp.i_group_id;
END LOOP;
RETURN
Hi All,
I'm wonder if there is any possibility to kick out automatically stuck in
queries after say 10 minutes or so?
I mean some kind of queries which calls eg. buggy functions with dead loops
or something similar.
Time to time I face such kind of problems which are solved automatically
after some
Looking at your query, I notice that the longer query happens when you
search on b.zcustnum=30538 while the LEFT OUTER JOIN remains the same.
It could be that when testing a.zcustnum=30530 the server can short
circuit the logic - it only has to check a.zcustnum to see if the
entire tuple shoul
26 matches
Mail list logo
