II locales. If you drop
the index on persistent_config.key, does the problem disappear?
regards, tom lane
ition is testing for equality between the two
parameters of the function. Since evidently that wasn't what you meant
to do, perhaps you'd be well advised to choose local-variable names that
don't conflict with column names of your tables...
regards, tom lane
fore
grouped views do not work very well, because the rewriter effectively
expands them in-line, thus converting your outer query into a grouped
query (or making it not work at all, if it was already grouped :-().
See related bug report just a few minutes ago on pgsql-bugs.
regards, tom lane
ileges to
> the trigger? How would I grant them privileges to the trigger?
Don't think there's a way to do that right now. There's been talk of
making triggers run "setuid" to the creating user, but it's not been
done AFAIR.
regards, tom lane
lation_name and
attrelid = c.oid and
atttypid = t.oid and
attnum > 0
order by attnum;
psql does a lot of these sorts of queries for its \d features.
Try starting psql with -E so you can see what queries it issues
when you do a \d ...
regards, tom lane
en't given us nearly enough information to have a shot
at figuring out what's going on.
regards, tom lane
match.
In any case, we don't even know whether this query used an indexscan...
regards, tom lane
mpiled by gcc 2.95.3
That's a rather interesting version report, seeing as how there is
no such gcc release as 2.95.3 according to the GCC project's homepage.
What compiler are you using exactly, and what confidence do you have
that it's bug-free? You wouldn't be using that known-unstable gcc
that RedHat shipped in their 7.0, would you?
regards, tom lane
d for 7.1 to the extent that you can
do examples like the above, but you still can't pass parameters to
the things --- for example CREATE TABLE $1 (foo int) won't work.
For these sorts of things you might want to consider pltcl or plperl,
which don't attempt to do any pre-parsing of SQL statements. A little
slower, but much more flexible...
regards, tom lane
n t_host matching the deletable
rows of t_haus? I'm wondering if there's some speed penalty associated
with trying to delete the same row multiple times in one command...
regards, tom lane
r count(distinct foo)
was added in 7.0, IIRC.
regards, tom lane
SELECT COUNT(*) FROM mytemp;
DROP TABLE mytemp;
regards, tom lane
ces. I'll make
sure it's fixed for 7.1.
regards, tom lane
gue)?
There isn't any code to scan through the table ACLs and remove
references to a particular group or user (if there were, DROP GROUP
would be invoking it already). Feel free to submit some...
regards, tom lane
comments do instead
(
insert into pg_description (objoid, description)
select old.att_oid, new.description WHERE old.description isnull;
update pg_description set description=new.description
where objoid = old.att_oid;
)
but I haven't tried it...
regards, tom lane
2
(1 row)
You can also use the SQL92 POSITION syntax:
play=> select position('ig' in 'high');
strpos
2
(1 row)
regards, tom lane
Mark Hollomon <[EMAIL PROTECTED]> writes:
> On Wednesday 29 November 2000 19:42, Tom Lane wrote:
>> Hm. Perhaps the "cannot update view" test is too strict --- it's not
>> bright enough to realize that the two rules together cover all cases,
>> so
ame date!
> -the date when the rule was created
Try now() instead of 'now'. The latter is coerced to a timestamp
constant as soon as the rule is parsed ...
regards, tom lane
tallation at all,
an initdb would be easier...
regards, tom lane
shoot this?
A gdb backtrace from the corefile, and/or a simple example to replicate
the problem...
regards, tom lane
which in pg_database, which is quite possible if
the executable and .bki files don't match.
In any case, it's a little bit silly to be installing 6.5.1 today.
I'd suggest removing all trace of Postgres from your machine and then
making a fresh installation of Postgres 7.0.2 (or wait
Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm. Perhaps the "cannot update view" test is too strict --- it's not
>> bright enough to realize that the two rules together cover all cases,
>> so it complains that you *might* be trying to up
e, whereas Perl might think
it only needs to flush stdout once per block.
Also, it looks like plperl supports elog(NOTICE, "text") and
elog(ERROR, "text"), though I haven't tried 'em.
regards, tom lane
;
> ERROR: parser: syntax error at or near "||"
I seem to recall that || (and most other operators) wasn't
considered associative by the grammar way back when.
Try a fully parenthesized expression:
select * from av34s1 where chromat ~~ (('%' || sample) || '%');
regards, tom lane
PS: And do think about updating soon, hmm?
amp))
return NULL;
in several places.
regards, tom lane
select substring(cp from 1 for 4)::int4 from out2cp;
?column?
--
3182
3182
(2 rows)
Does anyone else see a failure with this? If so what platform are you
on, and what build of Postgres are you using?
regards, tom lane
regards, tom lane
ion lookups are done only once, not once per tuple.
regards, tom lane
bounces from third-party recipients of pgsql list messages, let Marc
know ([EMAIL PROTECTED]). There's no point in bothering the rest of the
list with it, though --- Marc is the only one in a position to do
anything about it.
regards, tom lane
name used to set the timezone.
regards, tom lane
Alessio Bragadini <[EMAIL PROTECTED]> writes:
>> You must use same names (definitions) as are used in your OS
>> (an example on Linux at /usr/share/zoneinfo)
> In 7.1 works. Is it supposed to work also in 7.0?
Yes; as far as I know this hasn't changed...
cause the constants have their types adjusted, but when you write "url
= $1" you'd best make sure $1 is declared exactly the same way as url.
7.1 fixes some instances of this gotcha, but not all of 'em IIRC.
regards, tom lane
1" is
returning more than one row. Perhaps you want WHERE parentid IN subselect
rather than WHERE parentid = subselect. "=" is a scalar operator, not
a set operator.
regards, tom lane
. Use a timestamp
column for the primary key, and away you go.
(Actually, time alone doesn't seem like it'd be necessarily unique,
so maybe you don't want to call it a primary key. But certainly
you can make a non-unique index on that column.)
regards, tom lane
ICE: QUERY PLAN:
> Sort (cost=12692.74 rows=202175 width=16)
> -> Index Scan using wetter_pkey on table (cost=12692.74 rows=202175 width=16)
That's not very informative, since you haven't told us what that index is...
regards, tom lane
ol2)". Using data as a regexp
or LIKE pattern is sheer folly, unless you are *certain* that it can
never contain pattern-operator characters.
regards, tom lane
em is something along the lines of a table
with no owner (ie, no corresponding entry in pg_shadow), but can't
tell for sure yet.
regards, tom lane
Kaare Rasmussen <[EMAIL PROTECTED]> writes:
> In the dox I read:
You're reading the 7.1 docs. 7.0 docs live at
http://www.postgresql.org/users-lounge/docs/7.0/postgres/postgres.htm
regards, tom lane
ANALYZE, so there's a risk the planner will make the wrong
choice.
regards, tom lane
postgresql.org should
turn up a link...
regards, tom lane
27;<' operator. You could probably make one if you were intent
on it (see contrib/array for some inspiration). A lazier way out is
to use UNION ALL, which doesn't try to eliminate duplicates.
regards, tom lane
Try doing the two inserts in one rule:
CREATE RULE ... DO INSTEAD
(
INSERT INTO ... ;
INSERT INTO ... ;
);
This is the only way of controlling the order in which the actions will
be done; separate rules will be applied in an undefined order.
regards, tom lane
() to let you do exactly that.
regards, tom lane
Ferruccio Zamuner <[EMAIL PROTECTED]> writes:
> expire date default 'infinity');
> ERROR: Unrecognized date external representation 'infinity'
infinity is a timestamp (or datetime) feature, not a date feature.
regards, tom lane
doesn't exist.
Odd. The three statements work just fine for me when executed by hand
in 7.0.3. Anyone else able to reproduce a problem?
regards, tom lane
s. The 7.1 function manager removes that hardwired assumption,
but in 7.1 the plpgsql, pltcl, plperl function language handlers don't
take advantage of the capability --- so the current state of affairs
is that you can do it in SQL or C functions only. Hopefully this will
be improved in future releases.
regards, tom lane
a plpgsql function can recurse.
regards, tom lane
the pghackers archives. I made a proposal on 13-May-2000 that
I think was objected to by some people, though I don't recall exactly
why.
regards, tom lane
to find out what the difference
is, if any, but no luck yet.
regards, tom lane
any similar behavior for Unix sockets, however. Ideas anyone?
regards, tom lane
corner/docs/postgres/sql-language.htm#SELECT
and page down to "Subqueries". Note that the subquery-in-FROM feature
is new in 7.1.
regards, tom lane
is true that "SELECT b" isn't a valid SQL92 SELECT because it
hasn't got a FROM clause, but that's a minor quibble that just about
every vendor has invented a workaround for.
regards, tom lane
ht get 'xxxyyy' or 'yyyxxx' without forcing an order but
> I don't actually care in this case.
Check. You don't have any control over the order in which input rows
will be presented to an aggregate function.
regards, tom lane
hat PG version are you using? What is
the table's declaration? There should be a core file from the backend
crash, in $PGDATA/base/fliprdb/core --- can you get a backtrace from
it with gdb?
regards, tom lane
for a
qualifier that looks like "indexvar = ($1 + 1)", which is what you
effectively have in this case ($1 being the Param passed in from
the outer plan). It only recognizes "indexvar = constant" and
"indexvar = param" as indexable expressions. Current sources do
better.
regards, tom lane
used when the grouped-by item contains a
subselect, however.
regards, tom lane
other case of trying to close a subplan twice ...
regards, tom lane
ven the declared column length limits.
Getting rid of the constraints might be your easiest workaround for now.
regards, tom lane
staff_details_phone_three" &
> "staff_details_managers_notes" constraints it works :
Are you absolutely certain that that's how it went? I think the most
likely story is just that you were hitting the length(varchar)-barfs-
on-NULL bug, and got confused about which combinations you'd tried.
regards, tom lane
problems in
the list archives. For 7.1, we've gone so far as to disable
the optimization altogether in non-ASCII locales (and I'm sure
we'll get complaints about that, too :-().
regards, tom lane
Justin Clift <[EMAIL PROTECTED]> writes:
> BTW - How do things normally get added to the FAQ?
It's not a FAQ until it's been asked, um, frequently. But you can
try to talk Bruce Momjian into adding it, if you like.
regards, tom lane
ress in future releases. Ideally I think
a function returning sets and/or tuples should be treated as a table
source, so that you'd write ... FROM function(args) AS alias, ...
regards, tom lane
rrent.
What PG version are you using, and with what timezone setting?
Is 2000-09-30 or 2000-10-01 a daylight-savings transition date in your
timezone?
regards, tom lane
hort.
Anyway, you probably forgot to do a full rebuild after changing config.h.
"make clean" before "make all" is the only way to be sure the
configuration change propagates to all the code. Don't forget you will
have to do an initdb, also, so back up your data with the old code first.
regards, tom lane
d "pgdump_oid" hanging
around in the database directory, no doubt leftover from some previous
pg_dump cycle. Manually removing the file should get you up and running
again. However, that just begs the question of why the file is there...
regards, tom lane
s NULL no matter what you try to return.
This is a longstanding deficiency that is fixed by the new function
manager in 7.1.
regards, tom lane
hat by dropping/rebuilding
such indexes, or with REINDEX.
regards, tom lane
but we probably do something pretty surprising :-(
regards, tom lane
id;
update t1 set amount = tt.sum where id = tt.id;
drop table tt;
You might wanna think about updating sometime soon...
regards, tom lane
Mikael Hedin <[EMAIL PROTECTED]> writes:
> SELECT COUNT (DISTINCT data ) FROM media;
> ERROR: parser: parse error at or near "distinct"
This is supported since 7.0. I suspect you are running an old release.
regards, tom lane
1*8K = 212meg, and it might be using
several. So running out of disk space is not out of the question. Did
you watch free space with df while the query was running?
regards, tom lane
chives for past discussion of this. We have
been unable to persuade the LDP that the maintainer of the Postgres
HOWTO is unfit to be trusted with sharp objects, let alone a HOWTO.
If we could take it away from him, we'd gladly do so.
regards, tom lane
d alias name are not optional.
regards, tom lane
to the plate to do the work...
regards, tom lane
ith USE_AUSTRALIAN_RULES #defined. See
http://www.postgresql.org/users-lounge/docs/7.0/postgres/datetime-appendix.htm
regards, tom lane
for doco on date_part().
regards, tom lane
could write it as something like
CASE WHEN Z_durch_soll = '286.45' THEN Z_durch_soll+0.25
ELSE Z_durch_soll+0.2 END
regards, tom lane
in the foot is to sometimes start
the postmaster from a boot script, and sometimes start it by hand from
a user login that has different locale environment than the boot script.
7.1 will have some defenses against this, but in older releases you
have to be careful.
regards, tom lane
oted \r
followed by a regular end-of-row marker.
regards, tom lane
er' field of the table's pg_class row to match the
'usesysid' field of the pg_shadow entry for the desired new owner.
Working out the exact UPDATE command to use is left as an exercise
for the student ;-)
regards, tom lane
happen when you use a conditional rule.
regards, tom lane
s to make the column be type text not varchar.
7.1 is more flexible about this ...
regards, tom lane
13, and do not take account of it in date/time
> calculations.
Could one of you try it in 7.1 (beta3 or later)? We've changed some
details of the way daylight-savings transitions are handled in
date-to-timestamp conversions, so I think this might be fixed now.
It's worth checking anyway.
Also, what do you get from '31/12/2000'::date::timestamp?
regards, tom lane
it conclusive, particularly
since you're probably using a different OS than I am (I'm on HPUX
10.20). It would be good to bang on it some more with NZ daylight
times --- as Christopher says, GMT+13 is a tad unusual.
regards, tom lane
foo
-
100
(1 row)
regression=#
Works fine for me in both 7.0.2 and current.
regards, tom lane
e should be something about this in the mail archives about 6 to 9
> months ago iirc.
Hm. Please re-submit details if this is still there.
regards, tom lane
; the first real support
for bitstrings is in 7.1.
regards, tom lane
Nested Loop (cost=0.00..5.14 rows=3 width=61)
-> Seq Scan on pg_shadow (cost=0.00..1.01 rows=1 width=32)
-> Index Scan using sd_grant_pkey on sd_grant
(cost=0.00..4.07 rows=3 width=29)
regards, tom lane
has seemingly been fixed. Was this problem actually fixed
> somewhere between 7.0.0 and 7.1beta3, or am I just getting lucky right now
Well, it was worked on ;-) ... that whole chunk of code was rewritten.
Whether it has new bugs remains to be seen, but the old bugs are gone...
ou've got a client that only understands the pre-6.4
protocol ... but is telling the postmaster it understands 6.4, else
the 'Z' wouldn't be sent. What is the frontend in question anyway?
regards, tom lane
CURRENT is evil and should be eliminated,
but it hasn't gotten done yet. See past discussions in the pghackers
archives.
regards, tom lane
| 2 |-1
(1 row)
which is the correct result given that rules are executed before the
original query. (Which is why you need a trigger for this...)
regards, tom lane
If you don't
want that, qualify the field name:
select author.id into id from author where name = $1;
Feel free to submit documentation updates to make this clearer...
regards, tom lane
values ( $1 ,0,0,username_in, password_in, $2 , $3 , $4 , $5 , $6 , $7 , $8 , $9
, $10 )
ERROR: Attribute 'username_in' not found
DEBUG: Last error occured while executing PL/pgSQL function iu_employee
DEBUG: line 26 at SQL statement
DEBUG: AbortCurrentTransaction
There should be a more direct way of doing this, but for now, the
postmaster logfile is the best recourse ...
regards, tom lane
IN
which is correct since the a/b join should have a join condition
that refers only to a and b.
regards, tom lane
y fa1 ;
> unfortunately I get this in result:
> ERROR: Illegal use of aggregates or non-group column in target list
Works fine in current sources. Try upgrading to something newer than
6.5.2 ...
regards, tom lane
ace else or
compiled them yourself then you might be vulnerable to this error.
Check the mail list archives for more info, eg
http://www.postgresql.org/mhonarc/pgsql-hackers/2000-08/msg00193.html
regards, tom lane
best to "make clean" then "make
all"), or you neglected to initdb, or some other procedural error.
regards, tom lane
work in 7.0 and later.
regards, tom lane
that's not happening in the EXECUTE case.
Jan, do you agree this is a bug? Is it reasonable to try to repair it
for 7.1? If we do not change the behavior of EXECUTE now, I fear it
will be too late --- some people will come to depend on the existing
behavior.
regards, tom lane
101 - 200 of 2610 matches
Mail list logo
