Hello :
I have comiple tcl 8.3.2 and tk 8.3.2
complete
but I want to compile postgresql 7.1.3
with tcl
./configure --with-tcl --with-tclconfig=/usr/local/tcl8.3.2/unix
--with-tkconfig=/usr/local/tk8.3.2/unix
make
and I got the error
gcc -pipe -O2 -Wall -Wm
First bug:
Cygwin with pgsql version: 7.4.3 ( I have gcc and ipc-daemon2 in my cygwin)
When I run ‘initdb –D database’, it
shows:
The database cluster will be initialized with locale C
creating directory database... ok
creating directory database/base... ok
creating directory da
The following bug has been logged on the website:
Bug reference: 7610
Logged by: Sam Wong
Email address: s...@hellosam.net
PostgreSQL version: 9.2.1
Operating system: Windows 7 64-bit
Description:
Repro SQL:
CREATE TABLE a (id text, primary key (id));
INSERT INTO a
The following bug has been logged online:
Bug reference: 4327
Logged by: Sam Wong
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Linux Debian
Description:Primary key not refresh after cascaded deleted
Details:
Say, I have two table A
Great day to you!
I tried to install postgresql 8.3.7 on Linux RedHat 7.2 platform.
Process of "configure" ends normally,
process of "gmake" ends with this output of errors:
{
gmake[3]: Entering directory
`/usr/home/install/postgresql-8.3.7/src/interfaces/
libpq'
gcc -O2 -Wall -Wmis
exe".
I'm pretty sure that Windows has known about forward slashes being path
delimiters since Windows 95 and the start of Win32. I know I normally
use forward slashes in XP when I'm at work!
--
Sam http://samason.me.uk/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
o should not be distinct.
The more awkward case (to me anyway) is that the standard says (1,NULL)
IS NULL should evaluate to TRUE.
I'd never noticed the ROW / RECORD dichotomy before; could one of these
be made SQL compatible and the other use more sane semantics?
--
Sam http://samason
On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
> 2009/8/31 Sam Mason :
> > The more awkward case (to me anyway) is that the standard says (1,NULL)
> > IS NULL should evaluate to TRUE.
>
> what?
>
> only (NULL, NULL) IS NULL is true
Bah, sorry you&#
'--i.e. PG silently chops of the 'able'. The bug would seem to
be in your code, but PG could maybe throw an error to tell you this is
what is happening?
A possible fix would be to have your ELSE clause as:
c.relkind::text
As that way the other branches would be interpreted as text and they
wouldn't be getting chopped off along the way.
--
Sam http://samason.me.uk/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Sep 01, 2009 at 05:49:25PM +0100, Sam Mason wrote:
> PG could maybe throw an error to tell you this is
> what is happening?
Would something like the included patch be accepted?
--
Sam http://samason.me.uk/
*** src/backend/utils/adt/char.c~ 2009-01-01 17:23:49.0 +
-
SELECT 'hi'||add(1,2);
It doesn't get anywhere. No need for "text 'hi'" in the second one
because || isn't defined for values of integer type.
--
Sam http://samason.me.uk/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Wed, Sep 02, 2009 at 12:36:00PM -0400, Robert Haas wrote:
> On Wed, Sep 2, 2009 at 11:55 AM, Sam Mason wrote:
> > In fact it doesn't seem to want to play ball at all. Even given the
> > apparently unambiguous:
> >
> > SELECT 1+add(1,2);
> > or
> >
On Wed, Sep 02, 2009 at 01:19:07PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > ... For example:
>
> > CREATE FUNCTION add(int,int) RETURNS int LANGUAGE sql
> > AS $$ SELECT $1 + $2; $$;
>
> > CREATE FUNCTION add(int,int,int DEFAULT NULL) RET
On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > If we did follow Kevin's request directly, should we also be
> > specifying the type of NULL?
>
> I don't *think* the SQL standard requires that, and barring that I
> don&#
On Wed, Sep 02, 2009 at 01:27:35PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > you were requiring the types of literals that happened to be
> > enclosed in quotes to have their type ascribed, so why not the NULL
> > literal?
>
> Well, unless things have ch
stgresql.org/message-id/20090902091654.gl5...@samason.me.uk
--
Sam http://samason.me.uk/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.. ]
> }... ]
>
> The ball's in your court to show something in the standard to say that
> a character string literal is ever *not* to be taken as a character
> string.
Huh, you're right. I'd always thought '2001-01-01' was a valid date
literal, seems t
On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > If we did follow Kevin's request directly, should we also be
> > specifying the type of NULL?
>
> I don't *think* the SQL standard requires that, and barring that I
> don&#
On Wed, Sep 02, 2009 at 02:41:32PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
>
> > I'd always thought '2001-01-01' was a valid date literal, seems the
> > standard has required it to be prefixed by DATE at least back to
> > SQL92.
>
> Yep.
On Wed, Sep 02, 2009 at 02:59:54PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > CREATE VIEW v (c) AS
> > SELECT NULL;
> >
> > PG allows it, but the resulting view seems somewhat unusable.
>
> I'm not sure whether the only place the s
s the same as above.
> Much as the reason for the behavior of "char" may seem clear when
> inside the code looking out, it is astonishing for someone writing
> application code.
I think things would be clearer if an error was thrown in the
constructor of "char" types wh
On Fri, Sep 04, 2009 at 12:26:19PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > Kevin Grittner wrote:
> >> test=# select case when true then 'xxx' else 'a'::"char" end from t;
> >
> > 'xxx' is being used to initia
a lot like one:
You're getting bitten by implicit casts. Try creating a view of any
of your examples and seeing what the resulting types are, or in 8.4 an
EXPLAIN VERBOSE seems to show how it's typed the expression.
--
Sam http://samason.me.uk/
--
Sent via pgsql-bugs mailing list (p
e:
INSERT INTO t (id,rv)
SELECT f.id, b
FROM foo f
LEFT JOIN bar b ON (f.id = b.id);
Would fail if any bar's didn't exist, whereas the current behavior is
to insert a row with rv containing all null values. You can't test for
this case because IS NULL would return
On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > the deeper problem seems to be that the table was created as:
> >
> > create table test (a tstdom);
> >
> > and not as:
> >
> > create table test (a tstdom n
27;t be null for this column in this
table. Not sure if this is what people want though.
You then get into fun cases like:
create domain tstdom as integer;
create domain tstdom2 as tstdom;
--
Sam http://samason.me.uk/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Sorry, I mistyped that query in my bug report, damaging its credibility,
but the bug is actually there when you use "MI" for minutes:
template1=# select to_char(timestamp '2000-01-01 13:45:00', 'HH12:MI pm');
to_char
------
01:45 am
-
Sam Hokin
Any times between 12:00 and 14:00 show "am" rather than "pm". It shows
"pm" correctly for 14:00 and later.
My apologies if you've already addressed this, I haven't searched the
lists to see if it's already been reported.
-
Sam Hokin . mailto:[EMAIL PROTECTED] http://www.bsharp.org/sam
sr/slocal/src/postgresql-7.1/src'gmake:
*** [all] Error 2
what would be the problem ?
ths
Sam
The following bug has been logged online:
Bug reference: 2516
Logged by: Sam Howard
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4 -Deb Etch
Operating system: Linux - Debian Etch
Description:group privs do not seem to be honored
Details:
Trying to
The following bug has been logged online:
Bug reference: 3723
Logged by: Sam Mason
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux
Description:dropping an index that doesn't refer to table's columns
Details:
Hi,
foo (
one INTEGER NOT NULL UNIQUE CHECK (one = 1)
);
The bug (for me) was that it's possible to get the database into an
inconsisant state, with no warning or obvious way to back out.
Sam
---(end of broadcast)---
TIP 6: explain analyze is your friend
ve just downloaded the source of tinyerp and had a look though and
this practice seems pretty endemic. They should really be using
to_char(date_exp, '-MM')
instead of
substring(date_exp FOR 7)
in all their queries.
Sam
---(end of broadcast)
On Tue, Jan 01, 2008 at 04:29:47PM -0500, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > I've just downloaded the source of tinyerp and had a look though and
> > this practice seems pretty endemic. They should really be using
> > to_char(dat
readable. For future reference, the
pgsql-general mailing list[2] is more appropiate for questions like
this.
As a side note, do you have exactly one path from each node to another
node, or do you run this code several times until it converges on the
minimum? In the latter case you'd probab
hand? Its structure can be
> changed on-the-fly.
Sorry, I don't understand this comment. Could you elaborate?
Sam
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t always surprises me how little it's known
outside the functional programming community (ML and Haskell being the
old guard). Apparently, according to the fountain of wisdom that is
Wikipedia, It's finally starting to break into very mainstream languages
like the next versions of VB9 and C#
to see what MySQL did and
it seems to check for and handle this case--albeit only the 64bit case,
but as far as I can tell it only really knows about "long long" ints.
Sam
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sun, Apr 20, 2008 at 12:27:38PM -0400, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > Wouldn't it be easy to put some code like this in:
> > if (arg2 < 16)
> > return PG_RETURN_INT16(arg1 << arg2);
> > return PG_RETURN_INT16(0)
ble to think of a nice way of doing this though.
Sam
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
uestions. They are described here:
http://www.postgresql.org/community/lists/
Sam
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nting some function like "select
> ('07:00'<'12:00')".. i just want to know if is difficult to implement a new
> field called 'am', to use like.
>
> select extract(AM from '07:00');
What's wrong with just doing:
SELECT extract(h
And
when I do drop a table CPU usage goes to 99% on one CPU.
Sam
-Original Message-From: Sam Liddicott
Sent: 31 May 2002 10:57To:
'[EMAIL PROTECTED]'Subject: drop tempoary table VERY
slow
I have a DB where
this:
select 1 into
temporary table
orary tables when the connection
is closed.
I now "abort" all my
query sessions for speed.
I cannot reproduce
this on "template1" and it has not always been the case for my
DB.
Sam
Samuel
LiddicottSupport
Consultant[EMAIL PROTECTED]
Direct Dial: +44 (0)113 367
> -Original Message-
> From: Andrew McMillan [mailto:[EMAIL PROTECTED]]
> Sent: 02 June 2002 11:52
> To: Sam Liddicott
> Cc: [EMAIL PROTECTED]
> Subject: Re: [BUGS] drop tempoary table VERY slow
>
>
> On Fri, 2002-05-31 at 22:28, Sam Liddicott wrote:
> &g
> -Original Message-
> From: Andrew McMillan [mailto:[EMAIL PROTECTED]]
> Sent: 05 June 2002 12:58
> To: Sam Liddicott
> Cc: [EMAIL PROTECTED]
> Subject: RE: [BUGS] drop tempoary table VERY slow
>
> Interesting. Those are pretty long times to take for a
&g
lt must be on one of
the result columns
Full setup and steps taken are below.
Regards,
Sam
My setup:
Debian woody.
Linux 2.4.18.
PostgreSQL 7.2.1
./configure --with-maxbackends=64 --with-gnu-ld --enable-odbc
--enable-syslog
What I did:
# cat > test.sql << EOF
SELECT version();
t 100% cpu at times instead of
0.2-0.5 seconds or so.
Yet if I copy over the binary files when the DB's are stopped the new
machine is very fast at queries.
Could this be because the new machine started on 7.2.1 with a different
optimiser and so never generated query stats the the old box di
The following bug has been logged online:
Bug reference: 1432
Logged by: Sam Hahn
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows XP Pro v2002 SP 2
Description:type "cube" does not exist
Details:
When installing wi
Sorry... I thought I had checked "cube"...
Michael Fuhr wrote:
On Sat, Jan 22, 2005 at 02:25:27AM +, Sam Hahn wrote:
A database command error occured whilst executing
"E:\Program Files\PostgreSQL\8.0\share\contrib\earthdistance.sql":
ERROR: type &
50 matches
Mail list logo
