;
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
what you need, but it sounds
like the SELECT DISTINCT ON feature might solve it for you. Look into
our SELECT reference page at the weather reports example.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your
of newvalue from boolean to text causes problem.
What problem? 'true' and 'false' are accepted as input for boolean
AFAICS.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
like to think about it is WHERE filters rows before aggregate
functions are computed; HAVING filters them afterwards. Seen in those
terms, it's obvious why WHERE can't contain any aggregates.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org
fixed some
bugs with symptoms like that.
If you can reproduce it on any current release version, please send
a complete test case (the query alone is pretty useless without
tables to try it on) to pgsql-bugs.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql
.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Sofer, Yuval [EMAIL PROTECTED] writes:
postgres version: 8.2.0.4
ERROR: invalid input syntax for type inet:
fe80::104d:416e:a8dc:c02e%12
This is fixed in 8.2.5 and later.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make
Frank Bax [EMAIL PROTECTED] writes:
Kevin Duffy wrote:
ERROR: function regexp_string_to_array(text, text) does not exist
Are you running 8.3?
Also, it's regexp_split_to_array ...
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make
(hashcode)
= 33;
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
, which merges the similarly-named columns
into just one output column. RTFM, or any SQL book.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
behavior is
ill-defined if a given target row joins to more than one set of rows
from the other table(s).
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
from c;
commit;
The only thing this saves over just doing the full query is that you
don't have to transmit all the data to the client. Still, that can be
an important savings.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make
it, and it
should work.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
. But the FOR-loop all by itself isn't
going to return any data to the function's caller.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Steve Midgley [EMAIL PROTECTED] writes:
At 07:29 AM 7/16/2008, Tom Lane wrote:
I think what is happening is that ORDER BY knows that and gets rid of
the duplicate entries while DISTINCT ON fails to do so.
Of course removing the duplicate from both areas is the correct
solution and I broke
.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Emi Lu [EMAIL PROTECTED] writes:
Somebody know about how to find prepared query plan through command line?
PREPARE fooplan(...)
EXPLAIN EXECUTE fooplan(...)
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes
.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
the
documentation.
Advisory locks are defined as locking application-defined identifiers.
Why would you expect them to conflict with system locks, and what would
be the relationship exactly?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org
IS NOT NULL) THEN 1 ELSE 2 END,
-- search_rate_max,
property.id
LIMIT 10 OFFSET 0
BTW, why are you bothering with the CASEs at all? Null values of
search_rate_max would sort high already.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org
/100) \226 (sf \226 sf * comm/100)
as...
I'm not sure what character \226 is, but it's not a minus sign ...
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
six thousand full-time developers and an
already extremely mature database. Stuff that they see fit to add is
not necessarily going to be on our radar screen in the foreseeable
future.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make
.
An IN is not an equivalence condition.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
conditions.
I'm still dubious, but that's at least one less catalog search ...
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
performance by reducing the number of network round
trips needed to accomplish a multi-SQL-statement task
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
info_responsible to an int array would be reasonable.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
not, it can only
suppress rows at run-time; and what you've got is infinite macro
expansion recursion.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
values you want and use
an aggregate function to get it. So your query might end up looking
like
select a.id, min(a.foo), avg(b.bar), ... from ... group by a.id;
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your
reason for this
limitation or is it just the implementation waiting to be completed
(nobody has had an itch intensive enough to scratch it)?
The latter, I believe.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your
I'd look at option (1) before trying (2) with an
implicit cast.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
a bit you'll find multiple calls
happening.
(In recent releases you'd actually have a better chance of
not having multiple calls if you'd declared it volatile
instead of immutable.)
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make
wouldn't recommend that
unless the machine is entirely isolated from the internet.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
a tablefunc.so file that is compiled for 8.1
(copying the 8.3 version will almost certainly NOT work).
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
--- perhaps run a Perl script over the dump before you import.
There's no way those triggers will work, quite aside from your
difficulties in auto-generating them, because \0 isn't valid in
PG text values.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql
)
- a.size AS difference
FROM x a;
... but that'll be really slow for any significant number of entries.
not really... if you have an index on the TS column.
The OP said this was a view, so it may well not have any easy way to
provide such an index.
regards, tom lane
that overlaps is an equality condition (hint: it's not
transitive).
I don't say that it'd be impossible to construct an index type that
could do this, but you won't get there with the pieces we have.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql
really need microsecond, or even day, resolution in your dates?
I wonder if it'd not be good enough to store the year as an integer.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http
).
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
tab where intcol = intcol; delete from tab;
contains no literals and yet the delete is very probably injected.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
way to notice whether any insecure strings are
getting into database queries.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
/$', '');
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
This is already reported and fixed, thanks.
http://archives.postgresql.org/pgsql-bugs/2008-03/msg00275.php
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Craig Ringer [EMAIL PROTECTED] writes:
i = length(texto)
^^^
i := length(texto)
Whoops, I spoke too soon - it seems both are valid for assignment. Has
that always been true?
Yeah, it's not documented, but AFAIK plpgsql has always taken both.
regards, tom lane
think of automating it completely.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
.
Possibly the text should be reworded, with the mention of DBD::PgSPI put
somewhere else or stuck into a note or something.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
never be a reason for a deadlock, because no other
transaction could be trying to lock it.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
commands into a
file, so they can eyeball them before actually executing them.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
rather doubt that your source knows how
to change the intended file size from 16MB anyway ;-)
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
)
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
PostgreSQL 8.2.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.0.3
(Ubuntu 4.0.3-1ubuntu5)
8.2.3 is your problem --- this is fixed in 8.2.5 and up:
http://archives.postgresql.org/pgsql-committers/2007-05/msg00345.php
regards, tom lane
--
Sent via pgsql-sql
Conlon, Joseph F SIK [EMAIL PROTECTED] writes:
Does anyone think this is the correct behavior?
If you don't think so, you need to change to C locale.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your
:
http://archives.postgresql.org/pgsql-hackers/2005-01/msg00882.php
that suggest that constraint triggers are or have been deprecated.
However, their removal is no longer on the TODO as far as I can tell.
Yeah, there is no longer any thought of removing them.
regards, tom lane
on test, so
there must be something else going on that you didn't show us.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
probability that you have more
than one corrupted index. Keep reindexing tables until you can get
through a database-wide VACUUM.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
that these queries are moving targets: they frequently change
from one PG version to the next.
By far the best answer, if you can use it, is to invoke pg_dump itself
as a subprocess. Something like pg_dump -s -t mytable ... for
instance.
regards, tom lane
--
Sent via pgsql-sql
of the whole database.
You ought to look into why this happened, too. Since you've provided
precisely 0 context about PG version or platform, it's hard to speculate
about that ...
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes
;
that is, what you wrote is equivalent to
select * from t2 where id1 in (select t2.id1 from t1);
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
- if I create an empty table to go with
it, it runs here.
The error sounds suspiciously like what would happen if you tried to
use RETURN QUERY in a pre-8.3 version.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your
.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your Subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-sql
Alex Hochberger [EMAIL PROTECTED] writes:
Is it possible to grab access to the actually user-friendly error
message?
Doesn't the SQLERRM variable do what you want?
regards, tom lane
---(end of broadcast)---
TIP 4: Have
an index on a field wich is of a type
defined by the user?
Sure, if you are also willing to define operators and operator classes
on your type.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives
All to this message, I'd
appreciate it.
It bounced.
The OP should note that this is a good way to get shunned on these lists.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project
spots of our
own on questions like this one, so I'm disinclined to throw the first
stone ...
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe
sched.days;
Schema | Name | Object | Description
+--++-
(0 rows)
Try \d+ sched. I don't think \dd considers columns at all --- what
that command would be looking for is comments on table days in schema
sched.
regards, tom lane
for the lack of communication is that no one else believes
that premise. Casting a value to the same type it already has is
demonstrably a no-op.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support
), and no conversion between types is done.
It's not exactly clear what you checked, but it works as expected for
me. See test case below, proving that indexscan works just fine with
a parameter declared using %type.
regards, tom lane
regression=# create table tt(f1 char(10) unique
, this might be the easiest localized solution.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[EMAIL PROTECTED] writes:
Now, what do I have to do in order to generate a valid UUID (or the 5
different versions as implemented by the RFC) under Windows?
Figure out how to build ossp-uuid on Windows ...
regards, tom lane
---(end of broadcast
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Figure out how to build ossp-uuid on Windows ...
I think Windows has its own UUID generator, so the best bet would be to
make that work.
Only if it can be made to present the same SQL-level API as we have for
OSSP. Otherwise we'll
BTW, bouncing mail sent to your advertised reply address is a good way
to discourage people from ever answering you again.
regards, tom lane
--- Forwarded Message
Return-Path: MAILER-DAEMON
Delivery-Date: Sun Feb 10 21:57:56 2008
Received: from localhost (localhost
Dean Gibson (DB Administrator) [EMAIL PROTECTED] writes:
CREATE TYPE DATETIME AS (dummy TIMESTAMP);
I suspect not (syntax issues w/ input, output, etc). Is there an
alternate way to declare a type synonym?
CREATE DOMAIN would serve a lot better.
regards, tom lane
the relkind check.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
that are about tables that you have some access permissions
for. This might or might not confuse your app ...
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Steve Midgley [EMAIL PROTECTED] writes:
I'm wondering if there are any Bad Things that happen if I use negative
integers for primary key values in Postgres (v8.2)?
No.
regards, tom lane
---(end of broadcast)---
TIP 4
at).
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
why I am using the to_timestamp.
Locale has nothing to do with this --- at most you might want to adjust
the datestyle parameter.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
hack for text keys.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
configuration file.)
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
, the standard input converter is a whole lot
more flexible for slightly-out-of-spec input ... so I ask again,
do you really need to_timestamp at all?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
...
b) If a named columns join is specified, then every column
name in the join column list shall be the column name
of exactly one column of T1 and the column name of exactly
one column of T2.
regards, tom lane
answers in various corner cases, but I'm not sure there is
a right answer.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
, it's not too surprising that they'd show such a
weak grasp of correct syntax. Maybe replace the comma with CROSS JOIN?
... (SERVICE suv CROSS JOIN SERVICE sus) ...
regards, tom lane
---(end of broadcast)---
TIP 5: don't
timestamps.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
of course cannot be
patched. (According to the CVS tags the revisions of plancat.c and
predtest.c in the 8.2.6 release are 1.127 and 1.10.2.2, respectively,
whereas the patch is against the head revisions.)
Better look again.
regards, tom lane
---(end
forgot to declare num_matches as a local variable, too.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
WITH TIME ZONE
If you need to port from a system that used DATETIME as a type name,
consider defining DATETIME as a domain over whichever of the standard
types seems to have the closest semantics (likely the last of these).
regards, tom lane
---(end
of decimal digits, nor of any other character that would be allowed in
input for a decimal field. I can't tell what your problem really is,
but you have certainly misunderstood or misexplained it.
regards, tom lane
---(end of broadcast
; they're something or other
in Arabic, apparently. So I think you've got a problem in your Unicode
conversions as well as a notational problem.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
Joe [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, you've got two problems there. The first and biggest is that
#NNN; is an HTML notation, not a SQL notation; no SQL database is going
to think that that string in its input is a representation of a single
Unicode character. The other
to have access to the set of deleted rows,
and then you'd be stuck either scanning the table or having TRUNCATE
act differently from plain DELETE.
My feeling is that if you want to know what was deleted, you shouldn't
use TRUNCATE.
regards, tom lane
rowset information, even after we
add that for the other types of statement-level triggers.
Never mind ...
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
till previous step was done.
Too tired to experiment, but you may need a pg_ctl reload or even a
restart to get PG to notice changes in your timezonesets file.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help
/postgresql/timezonesets/Default, if you're using 8.2.
In earlier versions the table is hardwired into datetime.c :-(
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
a
different default for inserts to the view than for inserts
directly to the underlying table.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
by internal commands such as those generated by \d commands.
Another alternative is to run pg_dump -s -t table; that will get you
a lot closer to SQL-ready output, and you won't need to worry as much
about updating your code for future system catalog changes.
regards, tom
.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
301 - 400 of 2222 matches
Mail list logo