This is a minor problem, but maybe easily fixed? ...
If you create a database and load in the following sql, dump it with pg_dump,
then try to restore it (psql -e db < dump), it will get a parser error loading
the function when it encounters the "\'" in the regsub functions. I've had many
troub
I wrote:
> Oooh, I see it ... nasty! fixedlen_like is effectively assuming that
> it can access one byte beyond the end of the data string. You've
> managed to set up a situation where one byte beyond falls off the
> end of the world (or the end of the backend's allocated memory, anyway).
Turns
I had your prior message on my "to look at" list; the behavior seems
pretty odd. Two questions:
1. Which version are you running, exactly?
2. Might 'peripherals & access' happen to be the largest (last in
sort order) keyword present in your table?
If #2 is true, then this might rep
I've notice on certain queries, I was waiting a long time for a return so I
set out to troubleshoot something here's what I ran into...
When I do a explain on a select looking for 'peripherals & access' it uses
sequential scan but any other keyword uses index scan.
I've ran the vacuum analyze on P
On Thu, Jul 06, 2000 at 05:03:21PM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > #2 0xdaa41 in fixedlen_like (
> > s=0x1eeff4 "MQZSVRSJDSFR"... , p=0x1bdbe0,
> > charlen=12) at like.c:53
> > #3 0xdab1d in textlike (s=0x1eeff0, p=0x1bdbe0) at like.c:10
On Thu, Jul 06, 2000 at 03:18:59AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > What I can do is create a fake dataset, find some values that cause the problem,
>then give
> > that to you. Would that be acceptable?
>
> Sure, if you can do that. I just want
"Robert B. Easter" <[EMAIL PROTECTED]> writes:
> If you use min(x) or max(x) frequently, isn't it best to make a
> trigger that intercepts x on insert and update, then check it and
> store it somewhere rather than scanning for it everytime?
I believe that's exactly what the original questioner is
"Robert B. Easter" <[EMAIL PROTECTED]> writes:
> SELECT 3 !;
> ERROR: parser error at or near ""
> SELECT 3 !
> ;
> Works ok.
> Parser error occurs if the ending ; is on the same line.
Curious that
select 3 ! ;
works differently from
select 3 !
;
It appears that psql str
Paul McGarry <[EMAIL PROTECTED]> writes:
> Would that mean that any update that used an aggregate function
> would be invalid? That would be a bit scary seeing as I am doing
> this in part to get around using aggregate functions in a view.
You'd have to embed the aggregate in a sub-select if we d
On Fri, 07 Jul 2000, Tom Lane wrote:
> Chris Bitmead <[EMAIL PROTECTED]> writes:
> UPDATE foo
> SET bar = (SELECT min(f1) FROM othertab
> WHERE othertab.keycol = foo.keycol)
> WHERE condition-determining-which-foo-rows-to-update
> if you wanted to use an aggregat
Confirmed. That is really weird.
>
> SELECT 3 !;
> ERROR: parser error at or near ""
>
> SELECT 3 !
> ;
> Works ok.
>
> Parser error occurs if the ending ; is on the same line.
>
> --
> Robert
>
--
Bruce Momjian| http://candle.pha.pa.us
Chris Bitmead <[EMAIL PROTECTED]> writes:
> Another observation is that if the WHERE clause is successful, it seems
> to update the first record in the target relation that it finds which is
> a pretty random result.
Wouldn't surprise me --- leastwise, you will get a random one of the
input ctid
SELECT 3 !;
ERROR: parser error at or near ""
SELECT 3 !
;
Works ok.
Parser error occurs if the ending ; is on the same line.
--
Robert
SELECT : 1; -- returns e
Works, but gives a NOTICE that the : operator is depreciated and that
exp(x) should be used instead.
SELECT exp(1);
Gets ERROR: exp(INT4) does not exist.
SELECT exp(1.0);
Works fine of course.
Just seems strange that a depreciated operator actually works smoother.
--
Hi ppl,
I don't think this is related directly to PostgreSQL, but when trying to
compile using -O3 on a Linux/PPC box, the linker complains loudly that:
access/SUBSYS.o(.text+0x31fc8): undefined reference to `tas'
access/SUBSYS.o(.text+0x31fc8): relocation truncated to fit: R_PPC_REL24 tas
I do
Jan Ehrhardt <[EMAIL PROTECTED]> writes:
> I have recompiled postgres without -O2 and as far as I see
> all works well now (incl. getattproperties ).
OK, then it probably is an fmgr issue. This should be fixed in 7.1.
If you are willing to do a little extra legwork, you could try grabbing
curren
Hi Tom,
I have recompiled postgres without -O2 and as far as I see
all works well now (incl. getattproperties ).
Jan
Tom Lane wrote:
> Jan Ehrhardt <[EMAIL PROTECTED]> writes:
> > Architecture (example: Intel Pentium) : SGI Octane SI (MIPS R1)
> > Operating System (example: Linux 2.0
Another observation is that if the WHERE clause is successful, it seems
to update the first record in the target relation that it finds which is
a pretty random result.
pghack=# create table e(ee text, eee integer);
CREATE
pghack=# create table f(ff text, fff integer);
CREATE
pghack=# insert int
Tom Lane wrote:
> This seems like a backend bug to me, but being an overworked hacker
> I'm too lazy to try to reconstruct the scenario from your sketch.
> Could I trouble you to submit a formal bug report with a specific,
> hopefully compact script that triggers the problem?
I've attached it he
Paul McGarry <[EMAIL PROTECTED]> writes:
> CREATE TABLE entry_stats
> (
> entry_id INT4 NOT NULL REFERENCES entry ON DELETE CASCADE,
> entry_minprice INT4 NOT NULL DEFAULT 0
> );
>
> CREATE TABLE item(
> item_id INT4 PRIMARY KEY,
> item_entry_id INT4 NOT NULL REFERENCES entry ON DE
Here's the attachment I said I was going to attach to the last message.
TFIF!
--
Paul McGarrymailto:[EMAIL PROTECTED]
Systems Integrator http://www.opentec.com.au
Opentec Pty Ltd http://www.iebusiness.com.au
6 Lyon Park RoadPhone: (02) 9878 1744
North Ryde NS
Hi Tom,
> Hmm. There are several things going on here, but one thing that needs
> clarification is whether this UPDATE is written correctly. Since it
My goofup (you said you wanted a compact script!).
You are correct there should have been an extra where condition in
the triggered function.
=
22 matches
Mail list logo
