Mike Rylander wrote:
Thank you! This is great news. Is there a projected release date for 7.4?
Not exactly an officially projected date, but in the past IIRC beta/RC
has lasted 2 to 3 months, so I'd start looking for a 7.4 release in October.
Also, is there a published roadmap, or should I just
Ok, thanks.
I've applied changes to the source, recompiled and tested, everything is
working now.
Thanks a lot.
Regards.
On Fri, 2003-07-18 at 16:50, Maksim Likharev wrote:
> Try to EXPLAIN SELECT ..., if it crash you most likely have to recompile
> postgres with
> that strxfrm fix and it's hav
Thank you! This is great news. Is there a projected release date for 7.4?
Also, is there a published roadmap, or should I just get on the developers
list?
Thanks again.
---
Mike Rylander
On Friday 18 July 2003 05:34 pm, Joe Conway wrote:
> Mike Rylander wrote:
> > I have a rather odd table
Mike Rylander wrote:
I have a rather odd table structure that I would like to simplify to be a view
(for some definition of simplify). The current idea I have is to shovel
values from multiple rows in one table into an array in the view. The tables
look something like this:
Is anything like
I have a rather odd table structure that I would like to simplify to be a view
(for some definition of simplify). The current idea I have is to shovel
values from multiple rows in one table into an array in the view. The tables
look something like this:
create table person (
id serial,
n
On Fri, 18 Jul 2003, Yudie wrote:
> Hi,
> Anyone know how the procedure or commands to copy table to another database.
> or querying from another database if possible?
If you want to copy a table from one db to another, you can use this:
pg_dump dbname -t tablename |psql dbname -e
If you want c
Yudie wrote:
Hi,
Anyone know how the procedure or commands to copy table to another
database.
or querying from another database if possible?
thank you
yudie
Something like this, perhaps?
psql -d first_database -c '\copy mytable to stdout' | psql -d
second_database -c '\copy mytable from stdi
Hi,Anyone know how the procedure or commands to copy table to another
database.or querying from another database if possible?thank
youyudie
Josh Berkus wrote:
Well I suppose I could try TCL. The problem is that there is little to
no documentation on postgres stored procedures in TCL and I've never
even seen the language before. None the less, I'll look into it. It's
almost worth it. If that fails, I may even try perl .
And what's
Terence,
> Oh well, can't win them all :/
Nope. I'll suggest that for the TODO list ... we already have several
requests for added features for PL/pgSQL. The problem is that we currently
don't have a lead developer for PL/pgSQL, so the language has rather
stagnated.
> Well I suppose I coul
On Fri, 18 Jul 2003, Josh Berkus wrote:
> > I'm debugging a trigger in plpgsql and for some reason or the "select
> > into " does not seem to work. Here is an unaltered snippet of my
> > trigger code:
> >
> >raise notice ''this id : %'',NEW.id;
> >
> >select into i_hierarchy_i
Reinoud,
First, I'm moving your question to PGSQL-SQL, which is the appropriate list,
not HACKERS. See my response at the bottom of your quote.
> I'm debugging a trigger in plpgsql and for some reason or the "select
> into " does not seem to work. Here is an unaltered snippet of my
> trigger c
On Friday 18 July 2003 14:41, Chris Travers wrote:
> Hi all;
>
> I will be writing a stored proceedure that will allow a currently logged
> in user to change his/her password. The function needs to be only able
> to change the password of the currently logged in user, so it will only
> take a varc
Hi all;
I will be writing a stored proceedure that will allow a currently logged
in user to change his/her password. The function needs to be only able
to change the password of the currently logged in user, so it will only
take a varchar() argument and needs to look up the username of the
cu
On Friday 18 July 2003 10:18, Terence Kearns wrote:
> damn. There's realy no other way for me to access the value since the
> trigger function will be called from different relations.
>
> I tried idval := (''NEW.'' || TG_ARGV[3]); but recieved
> ERROR: pf_atoi: error in "NEW.blah": can't parse "NEW
Richard Huxton wrote:
On Friday 18 Jul 2003 9:22 am, Terence Kearns wrote:
I'm writing a trigger which wants to reference the pre-defined NEW record.
I can do this
idval := NEW.blah;
This works fine!!!
What I really need to do is
idval := NEW.(quote_ident(TG_ARGV[3]));
or this
idval := NEW.(TG_A
On Friday 18 Jul 2003 9:22 am, Terence Kearns wrote:
> I'm writing a trigger which wants to reference the pre-defined NEW record.
>
> I can do this
> idval := NEW.blah;
>
> This works fine!!!
>
> What I really need to do is
> idval := NEW.(quote_ident(TG_ARGV[3]));
> or this
> idval := NEW.(TG_ARGV
I'm writing a trigger which wants to reference the pre-defined NEW record.
I can do this
idval := NEW.blah;
This works fine!!!
What I really need to do is
idval := NEW.(quote_ident(TG_ARGV[3]));
or this
idval := NEW.(TG_ARGV[3]);
unfortunately this returns
"ERROR: NEW used in non-rule query"
I've
On Thursday 17 Jul 2003 8:39 pm, Steve Crawford wrote:
> OK, so basically you are trying to keep a hundered some odd attributes on
> everyone in the US. It's possible that a 150 column table is properly
> normalized (I have a similar situation) but it is rare.
>
> Suppose it is really properly norm
19 matches
Mail list logo
