Adam Mackler writes:
> On Wed, Aug 15, 2012 at 12:53 PM, Tom Lane wrote:
>> Right offhand I'm inclined to think that the reference to "iter"
>> inside the first sub-WITH ought to be disallowed. I don't recall
>> the exact rules about where a recursive reference can appear, but
>> it sure doesn't
Are you asking me or the other experts? I had not even heard of a
common table expression a few weeks ago, so I doubt I'm qualified to
opine what ought to be possible; I just know what I'm trying to do.
Basically I've got a recursive CTE with rows, some of which have
information that I want to be
Adam Mackler writes:
> WITH RECURSIVE
> tab(id_key,link) AS ( VALUES (1,17), (2,17), (3,17), (4,17), (6,17), (5,17) ),
> iter (id_key, row_type, link) AS (
> SELECT 0, 'base', 17
> UNION(
> WITH remaining(id_key, row_type, link, min) AS (
> SELECT tab.id_key, 'true'::text, iter.lin
On Mon, Aug 13, 2012 at 7:17 PM, Adam Mackler wrote:
>
> Next, uncomment the final UNION four lines from the end. When I do
> that I then get a two row result. I'm not an expert on recursive
> CTEs, but I don't believe a UNION should decrease the number of rows
> returned.
I haven't dug through
Hi:
I think I might have found a bug in the 9.2beta3 version. I'm kind of
new to SQL, so forgive me if I'm just misinterpreting correct
behavior. Given the query below, execute it. You should get a
seven-row result.
Next, uncomment the final UNION four lines from the end. When I do
that I the
Jeff Davis writes:
> The documentation says:
> "The specified null string is sent by COPY TO without adding any
> backslashes; conversely, COPY FROM matches the input against the null
> string before removing backslashes."
> -- http://www.postgresql.org/docs/devel/static/sql-copy.html
> Those s
The documentation says:
"The specified null string is sent by COPY TO without adding any
backslashes; conversely, COPY FROM matches the input against the null
string before removing backslashes."
-- http://www.postgresql.org/docs/devel/static/sql-copy.html
Those seem inconsistent with the follo
Jeff Davis writes:
> On Wed, Nov 30, 2011 at 5:10 PM, Tom Lane wrote:
>> The result of parse analysis for that query is a stored date constant
>> (in a Const node) with a cast-to-text on top of it. The system is aware
>> that cast-date-to-text isn't immutable, so it doesn't try to fold the
>> ca
On Wed, Nov 30, 2011 at 5:10 PM, Tom Lane wrote:
> The result of parse analysis for that query is a stored date constant
> (in a Const node) with a cast-to-text on top of it. The system is aware
> that cast-date-to-text isn't immutable, so it doesn't try to fold the
> cast operation. When you ex
On Wed, Nov 30, 2011 at 08:10:22PM -0500, Tom Lane wrote:
> Jeff Davis writes:
> > SQL:
> > set datestyle to postgres,us;
> > prepare stmt as select '02-01-2011'::date::text;
> > execute stmt;
> > set datestyle to postgres,euro;
> > execute stmt;
> > deallocate stmt;
>
> > The results
On Wed, 2011-11-30 at 20:10 -0500, Tom Lane wrote:
> I believe what is happening in the second case is that the query is
> getting re-parse-analyzed, from scratch, and since now datestyle is
> different (DMY not MDY), the date literal gets interpreted differently.
> You could argue it either way as
Jeff Davis writes:
> SQL:
> set datestyle to postgres,us;
> prepare stmt as select '02-01-2011'::date::text;
> execute stmt;
> set datestyle to postgres,euro;
> execute stmt;
> deallocate stmt;
> The results I get with normal debug compilation are:
> SET
> PREPARE
> text
>
SQL:
set datestyle to postgres,us;
prepare stmt as select '02-01-2011'::date::text;
execute stmt;
set datestyle to postgres,euro;
execute stmt;
deallocate stmt;
The results I get with normal debug compilation are:
SET
PREPARE
text
02-01-2011
(1 row)
S
Jeff Davis wrote:
> On Wed, 2011-02-09 at 22:58 -0500, Tom Lane wrote:
> > It's intentional ... not that other people haven't complained about it
> > before. Remember that what you have done is forced a crash, and
> > recovery from it is crash recovery. If we proactively removed such
> > files we
On Wed, 2011-02-09 at 22:58 -0500, Tom Lane wrote:
> It's intentional ... not that other people haven't complained about it
> before. Remember that what you have done is forced a crash, and
> recovery from it is crash recovery. If we proactively removed such
> files we would very possibly be dest
Jeff Davis writes:
> Case:
> BEGIN;
> CREATE TABLE foo AS SELECT generate_series(1,1000);
> CHECKPOINT;
> SELECT relfilenode FROM pg_class WHERE relname='foo';
> Let's say that returns 23456. Send the postmaster a SIGQUIT (immediate
> shutdown), and then restart. The file 23456 is still
Case:
BEGIN;
CREATE TABLE foo AS SELECT generate_series(1,1000);
CHECKPOINT;
SELECT relfilenode FROM pg_class WHERE relname='foo';
Let's say that returns 23456. Send the postmaster a SIGQUIT (immediate
shutdown), and then restart. The file 23456 is still in the filesystem,
but there's no
Tom Lane wrote:
> Jeff Davis writes:
> > On Thu, 2010-02-25 at 23:15 -0500, Bruce Momjian wrote:
> >> Was this ever addressed?
>
> > It doesn't appear to be fixed, and I don't see it on the TODO, either.
> > Should we add it there?
>
> +1. It likely wouldn't be real hard to fix, but given the l
Jeff Davis writes:
> On Thu, 2010-02-25 at 23:15 -0500, Bruce Momjian wrote:
>> Was this ever addressed?
> It doesn't appear to be fixed, and I don't see it on the TODO, either.
> Should we add it there?
+1. It likely wouldn't be real hard to fix, but given the lack of field
complaints I'm not
On Thu, 2010-02-25 at 23:15 -0500, Bruce Momjian wrote:
> Was this ever addressed?
>
It doesn't appear to be fixed, and I don't see it on the TODO, either.
Should we add it there?
Regards,
Jeff Davis
> ---
>
> Jeff
Was this ever addressed?
---
Jeff Davis wrote:
> On Thu, 2009-03-26 at 21:45 -0400, Bruce Momjian wrote:
> > > http://archives.postgresql.org/pgsql-bugs/2009-03/msg00062.php
> > >
> > > It may or may not be a real bug, but
:
> From: Kris Jurka
> Subject: Re: [BUGS] Possible bug with BYTEA and JDBC
> To: "Gregory Kotsaftis"
> Cc: pgsql-bugs@postgresql.org
> Date: Sunday, February 14, 2010, 4:42 PM
>
>
> On Sat, 13 Feb 2010, Gregory Kotsaftis wrote:
>
> > postgresql
On Sat, 13 Feb 2010, Gregory Kotsaftis wrote:
postgresql-8.4-701.jdbc4.jar
postgresql-8.5alpha3
I followed the steps in the blob tutorial and tried to test the BYTEA
example:
The 8.5/9.0 release has changed the default bytea output format and the
8.4 JDBC driver does not support it. You'
Hi,
I am using:
Windows XP Pro SP3 EN
JDK 1.6.0_u18
postgresql-8.4-701.jdbc4.jar
postgresql-8.5alpha3
I followed the steps in the blob tutorial and tried to test the BYTEA example:
http://jdbc.postgresql.org/documentation/head/binary-data.html#binary-data-example
I found out that the BYTEA data
Jeff Davis writes:
> Thank you for the explanation. My initial thinking was that either
> DoingCommandRead would protect us (for SIGINT to the backend), or we
> were going to terminate the process anyway (for SIGTERM). But it sounds
> like it leaves us in a state so unsafe that we can't even abort
On Fri, 2009-04-10 at 14:47 -0400, Tom Lane wrote:
> This patch is so wrong that it's scary. You can't have
> ImmediateInterruptOK true over the duration of any significant amount of
> backend processing --- as an example, if you take control away in the
> middle of a malloc call, you'll probably
Jeff Davis writes:
> Here is a patch that does what I think Heikki was suggesting. If a
> proper fix is non-trivial, then I assume there's some problem with my
> patch, but I'll post it for the archives anyway.
This patch is so wrong that it's scary. You can't have
ImmediateInterruptOK true over
On Thu, 2009-04-09 at 12:59 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Where are we on this?
>
> Pretty much nowhere --- there's no proposed patch, and I don't think
> it's exactly trivial. Do you want to put it on TODO?
Here is a patch that does what I think Heikki was suggesting. If a
Bruce Momjian writes:
> Where are we on this?
Pretty much nowhere --- there's no proposed patch, and I don't think
it's exactly trivial. Do you want to put it on TODO?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
Where are we on this?
---
Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > "SIGINT -- The server disallows new connections and sends all existing
> > server processes SIGTERM, which will cause them to abort their current
>
On Fri, 2009-03-27 at 15:43 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I'm not too familiar with this code, but I think we could just enable
> > ImmediateInterruptOK in CopyGetData().
>
> Only if you are wanting to break things.
>
Doesn't DoingCommandRead protect us in the SIGINT
On Fri, 2009-03-27 at 15:43 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I'm not too familiar with this code, but I think we could just enable
> > ImmediateInterruptOK in CopyGetData().
>
> Only if you are wanting to break things.
>
> The reason we don't allow client read to be inter
Heikki Linnakangas writes:
> I'm not too familiar with this code, but I think we could just enable
> ImmediateInterruptOK in CopyGetData().
Only if you are wanting to break things.
The reason we don't allow client read to be interrupted is the fear of
losing protocol sync on an incomplete messa
Jeff Davis wrote:
"SIGINT -- The server disallows new connections and sends all existing
server processes SIGTERM, which will cause them to abort their current
transactions and exit promptly."
http://www.postgresql.org/docs/8.3/static/server-shutdown.html
If you have an open COPY and no data is
Jeff Davis wrote:
The docs say:
"SIGINT -- The server disallows new connections and sends all existing
server processes SIGTERM, which will cause them to abort their current
transactions and exit promptly."
http://www.postgresql.org/docs/8.3/static/server-shutdown.html
If you have an open COPY
On Thu, 2009-03-26 at 21:45 -0400, Bruce Momjian wrote:
> > http://archives.postgresql.org/pgsql-bugs/2009-03/msg00062.php
> >
> > It may or may not be a real bug, but I didn't receive any response. If
> > you think it might be a bug, can you please add it to the open items?
>
> Hmm, odd I don't
Magnus Hagander wrote:
I have a patch working for me, I've sent it over to Gevik for testing in
his environment. Attached here if somebody else wants to play.
Looks OK.
cheers
andrew
---(end of broadcast)---
TIP 4: Have you searched our
On Thu, Feb 07, 2008 at 06:12:17AM -0500, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >On Wed, Feb 06, 2008 at 02:59:31PM +0100, Gevik Babakhani wrote:
> >
> >>I might be very wrong, but when I try to install 8.3 on Windows with NLS
> >>options selected, no share/locale files are insta
Magnus Hagander wrote:
On Wed, Feb 06, 2008 at 02:59:31PM +0100, Gevik Babakhani wrote:
I might be very wrong, but when I try to install 8.3 on Windows with NLS
options selected, no share/locale files are installed. could someone please
test or confirm this?
Yes, it's broken. It seem
On Wed, Feb 06, 2008 at 02:59:31PM +0100, Gevik Babakhani wrote:
> I might be very wrong, but when I try to install 8.3 on Windows with NLS
> options selected, no share/locale files are installed. could someone please
> test or confirm this?
Yes, it's broken. It seems the change in Install.pm rev
I might be very wrong, but when I try to install 8.3 on Windows with NLS
options selected, no share/locale files are installed. could someone please
test or confirm this?
Regards,
Gevik.
---(end of broadcast)---
TIP 1: if posting/reading through Us
Thank you
With UNION ALL the SQL work correct for my case...
Dario.
Tom Lane escreveu:
Dario Basso Cardoso <[EMAIL PROTECTED]> writes:
I receive two (2) rows if i union with other table i receive one (1) row!!!
You do know that UNION is defined to eliminate duplicate output rows?
(
Dario Basso Cardoso <[EMAIL PROTECTED]> writes:
> I receive two (2) rows if i union with other table i receive one (1) row!!!
You do know that UNION is defined to eliminate duplicate output rows?
(UNION ALL doesn't eliminate duplicates, and might be what you want.)
If that's not what you're seein
Hi,
I have PostgreSQL 8.0.3 for Windows XP and i have in attach the database
with problem.
The problem occour with this SQL
select proextra.data as data, 0 as codigo, proextra.motivo as nome, 'X'
as tipo, proextra.qtd, 0 as valor_u, 0 as cod_v from proextra where
proextra.data>=to_date('28/
Thank you for your responses. I got impatient and tried installing 8.0.2
and had no problems whatsoever. I will follow up on your suggestions if
I get to install 8.0.3.
Thanks again.
On Thu, 2005-09-22 at 11:23 -0400, Tom Lane wrote:
> "Prasad Duggineni" <[EMAIL PROTECTED]> writes:
> > Try turni
"Prasad Duggineni" <[EMAIL PROTECTED]> writes:
> Try turning the enforcement mode off.
Or put the data directory where the standard selinux policy expects it
to be, namely /var/lib/pgsql/data.
The lack of any useful error message is a selinux policy bug, which
appears to be fixed in reasonably-c
Try turning the enforcement mode off.
- Original Message -
From: "SriKumar Kareti" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, September 21, 2005 2:49 PM
Subject: [BUGS] possible bug...
Hello!
I am trying to install postgres 8.0.3 from rpms.
[EMAIL PROTECTED] ~]
On Wed, Sep 21, 2005 at 01:49:35PM -0500, SriKumar Kareti wrote:
Hi,
> creating directory /usr/local/pgsql/data/base/1 ... ok
> creating directory /usr/local/pgsql/data/pg_tblspc ... ok
> selecting default max_connections ... 10
> selecting default shared_buffers ... 50
> creating configuration f
Hello!
I am trying to install postgres 8.0.3 from rpms.
[EMAIL PROTECTED] ~]$ rpm -qa | grep postgres
postgresql-8.0.3-1PGDG
postgresql-server-8.0.3-1PGDG
postgresql-libs-8.0.3-1PGDG
[EMAIL PROTECTED] ~]$
After I install the RPMs, when I try to initdb I run into problems.
I did set the data dir
Tom Lane wrote:
! maskl = (0xUL << (32 - (int)
bits))
! & 0xUL;
Is that "& 0xUL" required ?
---(end of broadcast)---
TIP 8: explain analyze i
POSTGRESQL BUG REPORT TEMPLATE
Your name : Thomas Jacob
Your email address : [EMAIL PROTECTED]
Sys
[EMAIL PROTECTED] writes:
> So I'm guessing there is something wrong with the way 0.0.0.0/0 is being
> recognized?
Hmm, I'm betting you are on a machine where shifting a 32-bit quantity
left 32 bits doesn't reliably give zero. This misbehavior is actually
allowed by the C standard :-( ... but it
Hey guys,
I'm a fairly new user to the postgresql world... so *perhaps* this is not a
bug. But I cannot get
the following entry to work in the pg_hba.conf file:
hostall all 0.0.0.0/0 md5 <-- doesn't work
hostall all 4.0.0.0/8 md5 <-- matches anything 4.x.x.x (wor
On Sun, Oct 31, 2004 at 03:37:26PM +, Ralph Heinkel wrote:
>
> I think this is a bug (I hope not a feature).
It's a feature.
> For each insert into table 'tmp' the serial counter is increased
> twice, once to create the entry in 'tmp', once for 'log'. The problem
> is that the rule does not
Ralph Heinkel wrote:
Hi,
I think this is a bug (I hope not a feature).
Description:
The table 'tmp' gets records added, and uses a serial to fill
the attribute 'strorage_id'. The table has a rule which logs
all inserts into the table 'log'.
Problem:
For
Hi,
I think this is a bug (I hope not a feature).
Description:
The table 'tmp' gets records added, and uses a serial to fill
the attribute 'strorage_id'. The table has a rule which logs
all inserts into the table 'log'.
Problem:
For each insert into tab
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> Do we still need a backported fix?
No. This is a behavioral change of a *very* longstanding behavior.
It's going in at 8.0, not 7.4.something.
regards, tom lane
---(end of broadcast)-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Wed, 6 Oct 2004, Tom Lane wrote:
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
Am I missing something, or is it a bug? I can't reproduce it in 8.0beta2.
whereas prior versions did the rollback but still reported the command
tag as COMMIT. AFAIR, Po
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> Am I missing something, or is it a bug? I can't reproduce it in 8.0beta2.
8.0 actually behaves the same way: the COMMIT gets you out of the
transaction block. It just tells you that it's treating it as a
rollback:
regression=# comm;
ERROR: syntax erro
On Wed, 6 Oct 2004, Devrim GUNDUZ wrote:
> [I say COMMIT on a failed transaction and it looks successful, but isn't.]
This is a long standing behavior. Internally a ROLLBACK happens, but
commit is reported back to the client. This has only changed in 8.0 to
reflect what actually happened.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm using 7.4.5 on a test platform and had a weird behaviour. Here is the
case:
test=# CREATE TABLE t1 (s_no int2 PRIMARY KEY,a varchar(10));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey"
for table "t1"
test=# CREATE TA
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> but these seem to have a constituency :-(
> I think it is reasoable to expect people to use an explicit cast when
> doing these conversions.
That's what I think, but I lost the argument last time round...
I th
On Fri, Jul 02, 2004 at 10:27:35 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> IIRC there were objections the last time it was seriously proposed,
> basically of the form "but that will break my application which relies
> on writing so-and-so without a cast". We did get as far as removing all
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 1. Juli 2004 23:10 schrieb Tom Lane:
>> Right. The reason PG doesn't error is that we have an implicit cast
>> from integer to text. I've opined before that we should mark most
>> cross-type-category casts as explicit-only ... they are
Am Donnerstag, 1. Juli 2004 23:10 schrieb Tom Lane:
> Right. The reason PG doesn't error is that we have an implicit cast
> from integer to text. I've opined before that we should mark most
> cross-type-category casts as explicit-only ... they are just too prone
> to give unexpected answers, as i
On Jul 1 2004, Stephan Szabo wrote:
Technically speaking, I believe the queries are simply invalid without the
presence of casts from the spec's standpoint.
Theoretically, I'd either expect both to give 0 rows (convert 3 into a
string and compare) or both to give 1 row (convert '003' to an integer
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Technically speaking, I believe the queries are simply invalid without the
> presence of casts from the spec's standpoint.
Right. The reason PG doesn't error is that we have an implicit cast
from integer to text. I've opined before that we should mark
On Thu, 1 Jul 2004, Ilir Gashi wrote:
> I saw this 'bug' reported in the Firebird SourceForge website for the
> Firebird 1.0 server. They confirmed it as a bug! I tried it in PostgreSQL
> 7.2 (I know its an old release but I do not have a newer version installed,
> and in any case I am only using
Hello,
I saw this 'bug' reported in the Firebird SourceForge website for the
Firebird 1.0 server. They confirmed it as a bug! I tried it in PostgreSQL
7.2 (I know its an old release but I do not have a newer version installed,
and in any case I am only using the server for reserach purposes).
Postg
>> With the help of two people from #postgresql at irc.freenode.org, I did a
>> initdb -d --pgdata data 2>debug.log and founded out that the problem was
>> that conversion_create.sql wasn't changing $libdir to the actual name
> It's not supposed to. I don't know what problem you had, but this is
"" <[EMAIL PROTECTED]> writes:
>> It's not supposed to. I don't know what problem you had, but this is
>> the wrong fix.
> But the problem was solved with the change. I'm not a postgres master
> at all, so, how postgres knows what to use on the libdir variable?
> Where the variable is defined? H
"" <[EMAIL PROTECTED]> writes:
> With the help of two people from #postgresql at irc.freenode.org, I did a
> initdb -d --pgdata data 2>debug.log and founded out that the problem was that
> conversion_create.sql wasn't changing $libdir to the actual name
It's not supposed to. I don't know what pr
Hello,
I had a problem with PostgreSQL 7.3.4, the pg_conversion table was empty after
initdb, so, no conversion could be made. I did exactly this:
# tar xvzf postgres-7.3.4.tar.gz
# cd postgres-7.3.4
# ./configure --prefix=/var/lib/pgsql --with-java --with-openssl
--without-readline
# make
#
Title: Possible bug with regards to multiple persistant connections
The operating environment in which this occurred is:
Apache 1.3.27
PHP 4.2.3
PostgreSQL 7.3.2
Redhat Linux 7.2
ADODB for PHP version 3.10
I have a database with an associated owner. I
Using postgres 7.2.3 the query planner seems to lose interest in using
indexes when DISTINCT is used.
Sample query without DISTINCT:
SELECT
ps_7.id,
FROM
ps_7,
page
WHERE
page.id = ps_7.id
ORDER BY
ps_7.id DESC
LIMIT 5;
NOTICE: QUERY PLAN:
Limit (cost=0.00..33.22 rows=5 width=16)
Nick Howden <[EMAIL PROTECTED]> writes:
> Using postgres 7.2.3 the query planner seems to lose interest in using
> indexes when DISTINCT is used.
I don't think this is a bug. DISTINCT requires a sort step, so even
though you have a LIMIT, the planner has to plan on the basis of reading
the entir
Using postgres 7.2.3 the query planner seems to lose interest in using
indexes when DISTINCT is used.
Sample query without DISTINCT:
SELECT
ps_7.id,
FROM
ps_7,
page
WHERE
page.id = ps_7.id
ORDER BY
ps_7.id DESC
LIMIT 5;
NOTICE: QUERY PLAN:
Limit (cost=0.00..33.22 rows=5 width=16)
Matthew Wakeling <[EMAIL PROTECTED]> writes:
> I have encountered what seems to be a bad decision made by the query
> planner, on a quite simple query. I have attached a shell script which
> creates a large (180MB) sql script, to demonstrate the problem.
These queries are forcing the join order;
I have encountered what seems to be a bad decision made by the query
planner, on a quite simple query. I have attached a shell script which
creates a large (180MB) sql script, to demonstrate the problem. To
reproduce, execute the bash script, and pipe the stdout into psql.
Redirect the stdout of
Francis Reader <[EMAIL PROTECTED]> writes:
> To conclude, if you have many clients whose backends have infrequent write
> accesses and then long periods of inactivity, but whose connection to the
> database is left open, and other backends that are active which march on and
> create new wal files,
The following is a simple test case to demonstrate a backend not closing a
file descriptor to wal file, under Linux 2.4.17 and PG 7.1.3
In session1:
Using psql cmd, create a table.
Perform an insert on that table.
In session2:
Issue psql
run "ls -l /proc/*/fd/* | grep pg_xlog"
This will list
We are running pg 7.1.3. x86 Redhat 6.1 with 2.4.17 and glibc 2.2.2.
We have several s/w subsystems which keep some pg backends open for a VERY
period of time. (Well the whole time the machine is powered up.), and others
which have a short lifetime when connected to pg backends.
The total amount
Coax <[EMAIL PROTECTED]> writes:
> [ insert with an ON INSERT DO UPDATE ... rule ]
> Here's the output of PG7.1.2:
> test=# INSERT INTO forum
>(group_forum_id,posted_by,subject,body,date,is_followup_to,thread_id,most_recent_date)
> VALUES ('88760', '192470', 'asdfasdfsqdf', 'blah',
>'1014405669
Hiya! I think i've found a bug in postgres 7.2.
I have tested this on 1 box, running redhat 7.2 w/ both pg7.1.2 and pg7.2.
I've attached a dumpfile that allows you to execute this query:
INSERT INTO forum
(group_forum_id,posted_by,subject,body,date,is_followup_to,thread_id,most_recent_date)
"Chuck Handshy" <[EMAIL PROTECTED]> writes:
> When you pass a oid to the lo_open it doesn't seem to be able to accept
> it and cause and error to be generated in the log file: ERROR:
> lo_lseek: invalid large obj descriptor (0) <- Note descriptor (0), I
> passed 16832 to it as the oid.
Descriptor
I have used server version of the perl modules DBD::Pg and Pg. I have
looked over the modules and the DBI package and believe the problem
might be with the libq.
When you pass a oid to the lo_open it doesn't seem to be able to accept
it and cause and error to be generated in the log file: ERROR:
Peter Breton <[EMAIL PROTECTED]> writes:
> Is there something that I'm not understanding here, or is this a bug?
What locale are you using? Non-C locales have sorting rules more
complex than you seem to be expecting.
$ cat data
e
,
ke
k,
ken
k,
kens
k, P
ens
, P
$ LANG=C sort data
,
, P
e
ens
k
Hi,
On my Postgres system ( PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled
by GCC 2.96), I get the following odd behavior in string compares:
# Works -- e (ASCII code 101) is after comma (ASCII code 44)
select current_time where 'e' > ',';
# Works -- adding a k to the front of both strings
se
Great, thanks for letting me know Bruce.
Regards, Dave.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 12 October 2001 18:54
> To: Dave Page
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: [BUGS] Possible bug in ALTER TABLE RENAME
This appears to be fixed:
test=> CREATE TABLE sheep (cow text);
CREATE
test=> CREATE INDEX goat ON sheep (cow);
CREATE
test=> ALTER TABLE sheep RENAME cow TO chicken;
ALTER
test=> \d sheep
Table "sheep"
Column | Typ
Hi,
During testing of new revision control code in pgAdmin II, I've found that
renaming an indexed column in a table does not automatically update the
index column name in pg_attribute. pg_get_indexdef does return the correct
definition however:
helpdesk=# CREATE TABLE sheep (cow text);
CREATE
h
"Wendel Leibe" <[EMAIL PROTECTED]> writes:
> Here is the problem. If I try to insert a contact record as, "confUser."
> "psql" and my DBI driver for perl fails with a permission error on objects.
> If I give confUser permissions to write to the objects table the statement
> will execute.
Current
It's been discussed a fair bit in the mailing lists but I don't think it's
made the documentation. The triggers use SELECT FOR UPDATE to get the row
locks but that forces the update permission need. In 7.1 this should be
gone (Peter E had a patch to remove the most common cases of this).
Steph
I think I have found a bug with Postgres' permissions. I have combed
through the documentation, but I haven't been able to find an explanation
for the following problem.
First of all here is what I am running.
Postgress version 7.0.2 ,
OS Linux Red Hat 6.2
Kernel version 2.2.17
I have the fol
Your name : Suchandra Thapa
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : K6-2
Operating System (example: Linux 2.0.26 ELF) : linux 2.2.17
PostgreSQL version (example: PostgreSQL-7.0): Po
Actually, this is what the spec defines. You're using match
unspecified, which means:
- If no was specified then, for each row R1 of the
referencing table, either at least one of the values of the
referencing columns in R1 shall be a null value, or the value of
each referencing colum
> -Original Message-
> From: Richard Ellis [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, September 06, 2000 1:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [BUGS] Possible bug in referential integrity system
>
> > create table t1 (num int4, name text);
> &
I'm not sure what the supposed bug is...
> From: Alexei E Korneyev [mailto:[EMAIL PROTECTED]]
[ reformated by PS]
create table t1 (num int4 PRIMARY KEY, name text);
create table t2 (ref int4 references t1 (num) NOT NULL, val text);
insert into t1 values (1
Hello!
Keys phrase 'NOT NULL'
simple=# create table t1 (num int4 PRIMARY KEY, name text);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 't1_pkey' for
table 't1'
CREATE
simple=# create table t2 (ref int4 references t1 (num) NOT NULL, val text);
NOTICE: CREATE TABLE will create impl
The submit button on the form located at
http://www.postgresql.org/bugs/bugs.php?1 results in a report of a
parsing error, so I'm sending this here as the alternative.
Is the following a bug in the referential integrity system? This is
for PG 7.0.0. I realize that declaring the "ref" column in
100 matches
Mail list logo
