"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> create table test(f1 int4,f2 int4);
> insert into test (f1.f2) values (1,2);
> ERROR: cannot assign to a column of type integer because it is not a
> composite type
This diagnostic is not wrong. It might be a tad unhelpful, but I don't
think
The following bug has been logged online:
Bug reference: 1293
Logged by: Alexander Kirpa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: FreeBSD
Description:INSERT INTO test (f1.f2) VALUES (1,2) - wrong diagnostic
Details:
create
The following bug has been logged online:
Bug reference: 1292
Logged by: shigeto aya
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.2
Operating system: Red Hat Linux Advanced Server release 2.1AS/i686
(Pensacola)
Description:ecpg precompile bug (valiab
On 10/23/2004 10:08 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 10/22/2004 3:30 PM, Ed L. wrote:
Clean build of pgsql 7.4.5 on HPUX B.11.23 on ia64 with
--enable-thread-safety fails ... :(
Unfortunately that doesn't mean that the switch is required to cause
libpq to behave nic
On Fri, 2004-10-22 at 00:59, Davide Negri wrote:
> Hello,
>
> i have installed postgres 8.0 beta3 as a program on my pc on windows
> xp. I have read on the installation note file that postgres server
> will not run with administrative permissions. I have read on your
> forum that this happened be
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
>> And it
>> would produce exactly the same result anyway, because the only way there
>> could be implicit coercion steps at the top of the expression is because
>> step 3 put them there.
> Per your earlier comm
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
> Not without an initdb (to have another column to put it in).
We're already requiring an initdb for beta4; if this is the right way to
fix this (and I'm not insisting that it is), then ISTM we can just push
back beta4 a few days.
> And it
> would prod
On Sun, 24 Oct 2004, Tom Lane wrote:
> > (1) Accept the default's raw parsetree from the parser
> > (2) Convert it to a cooked parsetree via transformExpr()
> > (3) Add a coercion to the table's column type
>
> > Can't we save the cooked parsetree that we produced in #2?
>
> Not without an initd
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Possibly we should make ALTER COLUMN strip any implicit coercions that
>> appear at the top level of the default expression before it adds on the
>> implicit coercion to the new column datatype.
> That seems like a kludge. When processin
On Sun, 24 Oct 2004, Neil Conway wrote:
> (1) Accept the default's raw parsetree from the parser
> (2) Convert it to a cooked parsetree via transformExpr()
> (3) Add a coercion to the table's column type
>
> Can't we save the cooked parsetree that we produced in #2?
One could even save the strin
>I switched "in place" from beta2 to beta3 on windows some weeks ago
>(selfcompiled), no notable speed difference.
There may be a different issue here as well. The pginstaller version is
"beta3deva1", which is *not* beta3. It is a post-beta3 snapshot from oct
20th. If something has changed there,
Tom Lane wrote:
Possibly we should make ALTER COLUMN strip any implicit coercions that
appear at the top level of the default expression before it adds on the
implicit coercion to the new column datatype.
That seems like a kludge. When processing a column default expression, we:
(1) Accept the defa
> > I have read on the installation note file that postgres server will not
> > run with administrative permissions. I have read on your forum that this
> > happened because i have installed the beta version: is it true that this
> > happen only with the beta version?
It is written by the core dev
James,
that error is well documented in the PGINSTALLER-FAQ on pgfoundry.
Problem: "something" is interfering with socket-inheritance.
"something" most offen is some kind of "Layered service provider" as
is: Antivir software, Age Verfication Software..."
Workaround now: "something" has to be u
>ON UPDATE TO album WHERE new.pls_id != old.pls_id
> It works until new.pls_id or old.pls_id is null. The rule is still called
> (based on my test), but the "DO" query is not executed correctly. The
> values in "album_edit" are not updated.
To compare "NULL" to something is allways a bad ide
I switched "in place" from beta2 to beta3 on windows some weeks ago
(selfcompiled), no notable speed difference.
Did you the usual "analyze" ritual???
Are the indexes used? Did you compare the "explain" outputs?
Are the indexes really present?
Harald
---(end of broadcast
Enrico Riedel wrote:
To the setup: I use the Win32 version of PGRE SQL8. The table that I am
working with has about 1.1M records in it and is indexed on several columns.
By searching the indexed columns the DB used to be very fast. The data
retrieval used to be more or less instantaneous. In Beta 3
17 matches
Mail list logo
