OK,
I have discovered a problem with my auto-naming patch. It's do to with
dumping serial columns with pg_dump, eg:
--
-- TOC entry 2 (OID 1004551)
-- Name: users_users; Type: TABLE; Schema: public; Owner: chriskl
--
CREATE TABLE users_users (
userid serial NOT NULL,
firstname character
Tom Lane <[EMAIL PROTECTED]> writes:
> UPDATE totals SET
> xmax = (SELECT max(x) FROM details WHERE groupid = totals.groupid),
> ...
>
> but that is awfully tedious and will be inefficiently implemented. This
> is what Bruce is worried about. On the other hand, one could
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> IIRC, the SET does *not* start a transaction,
>
> > Yes but doesn't autocommit-off mode mean that
> > it implicitly begins a transaction in suitable
> > places ? For example, 'set autoco
Joe Conway <[EMAIL PROTECTED]> writes:
> Below is the Makefile. The key problem is that I need to get a "bundle"
> built instead of a "dynamiclib", or so I am told.
It's quite likely that the problem is in Makefile.shlib and isn't
specific to plr at all. Ask the complainant if plperl, pltcl, or
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> IIRC, the SET does *not* start a transaction,
> Yes but doesn't autocommit-off mode mean that
> it implicitly begins a transaction in suitable
> places ? For example, 'set autocommit to off;
> declare .. cursor ..' works though it neve
Hi,
I just noticed a bug in adddepend:
The below commands will upgrade the foreign key style. Shall I execute
them?
DROP TRIGGER "RI_ConstraintTrigger_1105102" ON news_authors;
DROP TRIGGER "RI_ConstraintTrigger_1105103" ON news_authors;
DROP TRIGGER "RI_ConstraintTrigge
*sigh* My system was stuffed. Fixed now. Please disregard this post -
sorry for spamming the list...
Chris
- Original Message -
From: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>
To: "Hackers" <[EMAIL PROTECTED]>
Sent: Friday, February 21, 2003 10:28 AM
Subject: [HACKERS] contrib/addde
When I run adddepend on my FreeBSD system, I get this:
> /usr/local/bin/adddepend -d usa
install_driver(Pg) failed: Can't locate DBD/Pg.pm in @INC (@INC contains:
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005 . /usr/libdata/perl/5.00503/mach
/usr/libdata/pe
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > I've been looking at the dependency API and I notice that there is a
> > function to delete ALL dependencies on an object and a function to add a
> > dependency, but there doesn't seem to be any way of deleting a
dependency
> > between two
Tom Lane wrote:
> UPDATE totals SET
> xmax = ss.xmax, xmin = ss.xmin, ...
> FROM
> (SELECT groupid, max(x) AS xmax, ... FROM details GROUP BY groupid) ss
> WHERE groupid = ss.groupid;
As long as any individual item that you can express in the
parenthesized (Informix) syntax
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Anyway should 'set autocommit to off;commit' cause
> > a warning or an error in the first place ?
>
> IIRC, the SET does *not* start a transaction,
Yes but doesn't autocommit-off mode mean that
it implic
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Anyway should 'set autocommit to off;commit' cause
> a warning or an error in the first place ?
IIRC, the SET does *not* start a transaction, so the COMMIT should raise
a warning.
I do not believe that eliminating the warning from COMMIT is a good
idea.
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > The simplest way seems to accept COMMIT any time under autocommit
> > off mode.
>
> That's just hiding the most visible symptom. The real problem here is
> that the SELECT is already committed, when it shoul
The current CVS version of PostgreSQL gives us the error:
ERROR: UNION/INTERSECT/EXCEPT member statement
may not refer to other relations of same query level
when given the following test case, despite the fact that the EXCEPT
clause does not refer to any other relation involved
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> On Thu, Feb 20, 2003 at 03:21:09PM -0500, Tom Lane wrote:
>> Provide a portable way of getting libc to tell us whether it likes TZ,
>> and I'll be glad to fix this.
> Dang that lovely word 'portable'. However, given your proposed change,
> perhaps
The right URL (I'll get it eventually) is
ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-02-Foundation-2002-01.pdf
That time I exactly copied the URL. sorry for the wrong one previously.
On 20 Feb 2003, Dave Cramer wrote:
> Scott,
>
> Thanks for the reference, I think the act
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> question about pgsql's time zone parsers. It appears there's at least
> two, since SET TIME ZONE accepts strings like 'US/Eastern', while general
> timestamp parsing doesn't:
The TIME ZONE string is fed to libc (via TZ environment variable); the
ot
Hello Teodor,
I'll check this maybe till the end of this week and try to write
some doc.
Thursday, February 20, 2003, 11:37:34 AM, you wrote:
TS> Changes:
TS> 1 Fixed compile problem on Solaris
TS> 2 Add search by weight of lexem.
TS> Readme: http://www.sai.msu.su/~megera/postgres/gist/tsearch
On Thu, Feb 20, 2003 at 09:31:21AM -0500, Tom Lane wrote:
> about. I originally understood Dave to be asking for parens to be
> allowed around individual target column names, which seems a useless
> frammish to me. What Bruce has pointed out is that a syntax that lets
> you assign multiple column
Hi,
Vincent van Leeuwen wrote, On 2/19/2003 10:08 PM:
On 2003-02-18 20:02:29 +0100, Peter Eisentraut wrote:
Christopher Kings-Lynne writes:
> REPLACE INTO anyone? ;)
The upcoming SQL 200x standard includes a MERGE command that appears to
fulfill that purpose.
MySQL features a poor-mans apro
On Wed, Feb 19, 2003 at 10:35:58PM -0500, Tom Lane wrote:
> Any objections?
Not to your suggestion per se, but looking at the bug report raises a
question about pgsql's time zone parsers. It appears there's at least
two, since SET TIME ZONE accepts strings like 'US/Eastern', while general
timest
sorry, it's the -02 document.
just change the last 01 to 02 and you'll get the right one.
On 20 Feb 2003, Dave Cramer wrote:
> Scott,
>
> I can't find page 858 in that document, is it the right one?
>
> also the link s/b ?
>
> ftp://ftp.sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4
I've written PL/R to make use of the contrib build system, and modelled
its Makefile after other contrib modules. One user who tried installing
PL/R under OS X sent me this:
The makefile does
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -fno-common -inst
Scott,
Thanks for the reference, I think the actual document is
ftp://ftp.sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-01-Framework-2002-01.pdf
and it is in section 14.12
on or about page 839
Dave
On Thu, 2003-02-20 at 11:20, scott.marlowe wrote:
> On Thu, 20 Feb 2003, Tom Lane w
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> The simplest way seems to accept COMMIT any time under autocommit
> off mode.
That's just hiding the most visible symptom. The real problem here is
that the SELECT is already committed, when it shouldn't be.
regards, tom lane
Informix supports 2 different styles for the update - your one would have to
be written :
UPDATE djp SET(col1, col2) = ((SELECT col1,col2 FROM some_other_table))
Notice the double brackets !
The first signifies a list of values - the second is the brackets around the
subquery...
(NB If you tr
Scott,
I can't find page 858 in that document, is it the right one?
also the link s/b ?
ftp://ftp.sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-01-Framework-2002-01.pdf
Dave
On Thu, 2003-02-20 at 11:20, scott.marlowe wrote:
> On Thu, 20 Feb 2003, Tom Lane wrote:
>
> > Hannu Krosin
On Thu, 20 Feb 2003, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Are you against it just on grounds of cleanliness and ANSI compliance,
> > or do you see more serious problems in letting it in ?
>
> At this point it seems there are two different things being tossed
> about. I
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > There seems a bad behavior under autocommit off mode.
>
> > 1) psql -c 'set autocommit to off;select 1;commit'
> > causes a WARNING: COMMIT: no transaction in progress
>
Hello...
I haven't been subscribed in a while, but I've got an issue and am trying to
determine if the Right Way(tm) is the quickest way to fix it.
Basically, I have some very expensive stored procedures that determine whether
a user should have access to particular rows in a query (not a postgre
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 20 February 2003 14:31
> To: Hannu Krosing
> Cc: Dave Cramer; Peter Eisentraut; Pgsql Hackers
> Subject: Re: [HACKERS] request for sql3 compliance for the
> update command
>
>
> Hannu Krosing <[EMAIL PROTECTED]>
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Thursday 20 February 2003 10:38, Tom Lane wrote:
>> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> There seems a bad behavior under autocommit off mode.
>
> 1) psql -c 'set autocommit to off;select 1;commit'
> causes a WARNING: COMMIT: no transacti
On Thursday 20 February 2003 10:38, Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > There seems a bad behavior under autocommit off mode.
> >
> > 1) psql -c 'set autocommit to off;select 1;commit'
> > causes a WARNING: COMMIT: no transaction in progress
>
> Surely that's a bug: t
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> There seems a bad behavior under autocommit off mode.
> 1) psql -c 'set autocommit to off;select 1;commit'
> causes a WARNING: COMMIT: no transaction in progress
Surely that's a bug: the SELECT ought to start a transaction block.
Barry Lind reported
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I've been looking at the dependency API and I notice that there is a
> function to delete ALL dependencies on an object and a function to add a
> dependency, but there doesn't seem to be any way of deleting a dependency
> between two _particul
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Bruce Momjian kirjutas N, 20.02.2003 kell 06:16:
>> However, what solution do we have for UPDATE (coll...) = (select val...)
>> for folks? It is awkward to repeat a query multiple times in an UPDATE.
> hannu=# update target set
> hannu-# a = source.a1,
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Are you against it just on grounds of cleanliness and ANSI compliance,
> or do you see more serious problems in letting it in ?
At this point it seems there are two different things being tossed
about. I originally understood Dave to be asking for paren
Hi guys,
Had an interesting conversation earlier on today with Timothy Witham
from the Open Source Development Lab (important place sponsored by IBM,
HP, CA, etc) earlier on today. They've been basing their database
performance suites on SAPDB, but are having problems with it and looking
to m
Changes:
1 Fixed compile problem on Solaris
2 Add search by weight of lexem.
Readme: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/README-V2.txt
Tar: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/tsearch.tar.gz
We still need a documentation...
Any comments please send to Oleg
Bruce Momjian kirjutas N, 20.02.2003 kell 06:16:
> Agreed folks are going to have bigger problems from Informix than just
> this, and in fact I used Informix for years and didn't know they allowed
> this.
>
> However, what solution do we have for UPDATE (coll...) = (select val...)
> for folks? It
Bruce Momjian kirjutas N, 20.02.2003 kell 06:16:
> Agreed folks are going to have bigger problems from Informix than just
> this, and in fact I used Informix for years and didn't know they allowed
> this.
>
> However, what solution do we have for UPDATE (coll...) = (select val...)
> for folks? It
Tom Lane kirjutas K, 19.02.2003 kell 21:12:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > Ok, if a patch were submitted to the parser to allow the syntax in
> > question would it be considered?
>
> I would vote against it ... but that's only one vote.
Are you against it just on grounds of cleanli
On Wed, Feb 19, 2003 at 04:37:33PM +0100, Peter Eisentraut wrote:
> That's not what my copy says.
Strange. I just looked at all the docs I have and all have it listed the
way Dave wrote. So I seem to have to update my docs. Peter, could you
send me a copy?
Michael
--
Michael Meskes
Email: [EMAIL
On Wed, Feb 19, 2003 at 12:29:12PM -0500, Tom Lane wrote:
> SQL99. Looks like the parens got lost again by the time of the final
> spec.
I don't think the parens really matter. It's just the different ordering
of columns and values.
Michael
--
Michael Meskes
Email: [EMAIL PROTECTED]
ICQ: 179140
44 matches
Mail list logo
