queries?
What about foo_id = 100 AND foo_id % 8 = 100 % 8 ?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a9911a711861381017743!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
in some cases. Is that possible?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a95273611861044619247!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
values are TOASTed though, they're rather short values; not quite 2k
anyway.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a954cda11869014116556!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
On 26 Aug 2009, at 16:55, Alban Hertroys wrote:
With the SET_VARSIZE the above should work *as long as datum is not
toasted (or packed)*. If it's been detoasted then that's good, or if
it was freshly generated and not stored in a tuple then it should be
good too.
I changed
= 1;
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a92716d11861465718119!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
for unit_token[].
Alban Hertroys
--
Screwing up is the correct approach to attaching something to the
ceiling.
!DSPAM:737,4a8eee7b10131407718702!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On 21 Aug 2009, at 22:12, Tom Lane wrote:
Alban Hertroys dal...@solfertje.student.utwente.nl writes:
I have created operators on unit_token for =, , =, and =, but
either I did something wrong defining my operators or the error is
pointing to some other problem.
The mere fact
about this very topic here recently.
Alban Hertroys
--
Screwing up is the correct approach to attaching something to the
ceiling.
!DSPAM:737,4a8bd41d10131434511488!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
On 18 Aug 2009, at 19:59, Alban Hertroys wrote:
Hello all,
Inspired by the original discussion on aggregating quantities of
different units I made a start at a unit conversion database and the
result is here: http://solfertje.student.utwente.nl/documents/units.sql
I just uploaded
on this ;)
Ah, no problem. Please keep posting release announcements. Maybe
on -announce if so.
Yes, announce would be the right place. I dislike it when people start
using this list for announcements of new versions of their software,
so let's not start doing that myself :)
Alban Hertroys
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
Screwing up is the correct approach to attaching something to the
ceiling.
!DSPAM:737,4a8a8ee410137968484637
are welcome.
On 18 Aug 2009, at 13:22, Alban Hertroys wrote:
In this case however we have far better tools, namely a computer
with a database. It's easy to create a table with units and their
conversion factor to a standard unit. If you go a bit further you'd
create a few tables linking
ON radical FOR
EACH ROW EXECUTE PROCEDURE history_radical();
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a87e8d010131556343596!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
if;
if cursor1.tipo_transaccion = 'CK' then
creditos := creditos + cursor1.monto;
end if;
if cursor1.tipo_transaccion = 'NC' then
creditos := creditos + cursor1.monto;
end if;
end loop;
Alban Hertroys
--
Screwing up is the correct
functions. You're much more flexible that way.
Alban Hertroys
--
Screwing up is the correct approach to attaching something to the
ceiling.
!DSPAM:737,4a83fca210137297812668!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
the regression tests from the console?
If that still doesn't show anything it's probably a good idea to run
the regression tests through trace, but that's probably going to
create a LOT of output to wade through. It should point you to the
culprit though.
Alban Hertroys
--
If you can't see
' as timestamp with time zone)
at time zone 'GMT';
timezone
---
2009-08-06 10:15:12.66097
(1 row)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a7aadf610131061822158!
--
Sent via
=*;BELFRY\
Others already commented on that fact that this line is never matched,
but is that space between master1. and belfry.lan intentional?
(The re-wrapping caused by indenting it for reply didn't make it more
obvious to see unfortunately)
Alban Hertroys
--
If you can't see the forest
command gets captured in a file and those are then
diffed with the expected output?
If so, isn't it just the output of stderr getting lost here? What
shell are you using?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
there is one)
is giving inconsistent results. Or the xid on the row itself is doing
something strange (vacuum would probably have fixed that?).
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a7abcfd10131523526886!
--
Sent
or not? They do not intend to enter valid
data after all ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a7820e510131352719414!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
On 4 Aug 2009, at 7:43, Andreas Kalsch wrote:
1) I have to rewrite many lines of code = time
Why? You do know that you can set multiple schemas in search_path do
you? It's a path ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see
it. It is an international website and the simplification is just
for indexing.
But I think that this will not solve the problem and I have to use
Python or Perl to get it done.
Alban Hertroys schrieb:
On 4 Aug 2009, at 24:57, Andreas Kalsch wrote:
I think the real problem is: Where do you lose
on the
connection and send it to a database that can handle UTF-8 then you
shouldn't be getting any conversion problems in the first place.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a77688810131526383955
partition constraints
into account too if you choose to use table partitioning.
Looking forward to your replies.
Janet
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a7581ec10134875916639!
--
Sent via
or identifier
quotation around the RETURN-type.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a75cff110131139260432!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
differences. I'd still not trust
the data in it afterwards, but whether that matters depends on what
you intend to use it for.
If you want safe and sound, use pg_dump/restore.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
, in which case there would be data loss if
it can't write there.
Caused by: org.postgresql.util.PSQLException: PANIC: could not write
to
log file 6, segment 176 at offset 14991360, length 8192: Read-only
file
system
You missed the interesting part: Read-only file system.
Alban Hertroys
you're running into this issue.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a6af5d410132049512701!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
tool.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a6995d910131993413858!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
like this: http://en.wikipedia.org/wiki/The_boy_who_cried_wolf
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a6437be10131991414558!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
still developing.
If you intend to handle conditions in the database, I suggest handling
the expression evaluation needed for that in a language other than pl/
pgsql, it will be much easier that way.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see
you're looking at that data from the same connection, or
if not, that the inserts get committed? I've seen data disappear if
people forgot they were in a transaction block and didn't commit at
the end.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see
On Jul 9, 2009, at 3:53 AM, Yaroslav Tykhiy wrote:
On 08/07/2009, at 8:39 PM, Alban Hertroys wrote:
On Jul 8, 2009, at 2:50 AM, Yaroslav Tykhiy wrote:
IIRC prefetch tries to keep data (disk blocks?) in memory that it
fetched recently.
What you described is just a disk cache
to ask about this on the FreeBSD mailing lists as
well, they'll know much better than I do ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a54776e10131807247821!
--
Sent via pgsql-general mailing list (pgsql
it seems like those other DB's use their comparisons
with null inconsistently, or they wouldn't be able to do outer joins...
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a548b0a10137687714970!
--
Sent via pgsql
this:
select date, sum(case when raw_text like '%RBL%' then 1 else 0 end) as
RBL, sum(case when raw_text like '%PRB%' then 1 else 0 end) as PRB
from zoa_pireps group by date.
It's probably a lot more readable if you wrap those expressions in an
immutable function.
Alban Hertroys
--
If you can't
with currencies anymore
THAT far into the future!
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a4a4f2d759151169695543!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
with by companies who co-locate your servers
plus they usually provide a reliable internet connection for them as
well.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a45e92b759151647533614!
--
Sent via pgsql
the newline. The fault is in the client though, so maybe
you don't want to handle that on the server-side.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a41e08a759153794312201!
--
Sent via pgsql-general mailing
like you'd be better served by a language that can
work with arrays of typed structures. As I'm not familiar with the
other PL languages I can't tell whether they would be suitable in that
respect, but I suspect Python or Java would be able to handle this
better.
Alban Hertroys
--
If you
the text.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a33833c759151518024860!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
.
What SQL_ASCII does is accept any value, regardless of encoding. It
basically just stores the bytes, even for multi-byte encodings.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a33842e759156622419335!
--
Sent
are available, but the database gets to check its
constraints against those operations as well and can throw an error
that prevents the file-system operation from being performed.
Apparently something like this shouldn't be too hard to implement
using FuseFS.
Alban Hertroys
--
If you can't see
to be able to deal with a foreign key
constraint violation or have some method to prevent those from occuring.
If you don't know what to choose for a given relation it's safe to
stick with the default, but you do need to think about what your
application needs to do in such cases.
Alban Hertroys
= $foo_id
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a1c2f7010091048315763!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
-datetime.html#FUNCTIONS-DATETIME-EXTRACT
). Maybe you should upgrade.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a1c33e310093700910733!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
0 end as segundo_campo_virtual
from (select *, campo1 - campo2 as campo_virtual from tabla) as tabla;
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a1a708910091961258073!
--
Sent via pgsql-general mailing list
.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a1a7e4d10092128944961!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
/mailpref/pgsql-general
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a17c3ee10091470919307!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
not to be accessible by the postgres user,
which displayed the behaviour you describe above.
I don't know the details, I rarely even use Windows, but this is what
I remember.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest
with the exact same layout? I don't quite see the benefit.
You could use the ENUM type for that (http://www.postgresql.org/docs/current/static/datatype-enum.html
), although that works best if these values are really static. If
users should be able to edit them they're probably not the best choice.
Alban
subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a16764110091025167268!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
with a simple join.
But as people often say here, premature optimisation is a waste of
time, so don't go that route unless you have a reason to expect
problems in that area.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
)
Or you ORDER BY effective_from DESC and use DISTINCT ON to ignore the
duplicates after the first match (which is the newest currency due to
the ordering).
I wonder whether it's possible to have effective_from dates in the
future though, that would complicate things slightly more...
Alban
the
constraint, at which point the database will verify that the related
records match the constraint. Of course this opens a risk where a
record gets inserted that doesn't match your FK constraint which will
cause recreation to error out and your transaction to rollback.
Alban Hertroys
--
If you
on this list (although
they're probably reading this as well). You'd probably be better off
asking there.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a06aec0129741990515020!
--
Sent via pgsql-general mailing list
for the rest of the input
according to Luhn''s algorithm.'
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,49fd82b6129742129210600!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
implementations.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,49fc1d20129743379199738!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
if it'd be similarly easy
to inspect the name and type of each column.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,49f82a8c129742043099112!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
On Apr 25, 2009, at 5:19 AM, pavunkumar wrote:
Dear Friend
Whatever your saying right , But why the function
not saying error ?
that is my doubt... this is what I want to
clarify!
Because it's a valid comparison, just not the one you wanted.
Alban
can fix it by uninstall and reinstall
PostgreSQL. But it happening repeatly.
Reinstalling shouldn't be necessary, it's probably enough to wait
until recovery is complete. The logs can tell you what's going on.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
could use UPDATE...FROM:
update entities
set customer_status = t2.customer_status
from entity_dimension_update as t2
where entity_id = t2.entity_id
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,49ed0151129747011493647
point of view.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,49e1ca98129741055947028!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
, it allows you to specify types for your data) so that you know
which fields to expect in the document.
You can query XML fields using xpath expressions in your queries.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
On Mar 31, 2009, at 6:41 PM, Harald Fuchs wrote:
In article 437faa9f-df2d-429e-9856-eb2026b55...@solfertje.student.utwente.nl
,
Alban Hertroys dal...@solfertje.student.utwente.nl writes:
You could add the columns you're sure that you need and put the rest
in an XML field.
mantra
If you
looking theories :)
Alban Hertroys wrote:
On Mar 25, 2009, at 5:09 PM, Mike Charnoky wrote:
Due to the nature of the sampling (need to limit using several
parameters with a WHERE clause), I can't just generate random
numbers to select data that I need. Looks like I am stuck using
ORDER
it's own disadvantages of course.
I've used something like that (as a function in our PHP application)
on a medium-sized data set before, and it performed adequately.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
, and since you don't know
where your intervals start and end I don't see how you could do that
without at least first generating your intervals. After that there
doesn't seem to be much use for the windowing functions, as a simple
group by seems to do what you want.
Alban Hertroys
--
If you
, so if someone searches for é in your forms it doesn't match
eacute; in your database) or data in your scripts that is hard to
compare (the value from a GET or POST request does not contain
entities while the value read and converted from the database does).
Alban Hertroys
--
If you can't
at that. I think my approach works as well as it
does because it's a procedural approach to a procedural problem.
If you'd like to see some code, I have posted about this in the past
and that contained some code examples. Just search the archives.
Alban Hertroys
--
If you can't see the forest
wasted trying to get a proper
question out of you...
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,49a7359f129748797120425!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
before you commit (or rollback if they don't). Create
savepoints before performing such tests so that typos in your test
queries don't invalidate your schema changes.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
in your
table. This way you shouldn't have your earlier problem with the
estimates.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4999b115747031962913450!
--
Sent via pgsql-general mailing list (pgsql-general
up in template1... oops!
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4991c5e6747031805728238!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
151332 * (21.418 -
1.418) = 3026640 ms, which is almost 12% of the total time.
The biggie seems to be the bitmap heap scan on rb though. The row
estimates for that one are way off (estimated 549 rows vs actual
151332).
Alban Hertroys
--
If you can't see the forest for the trees,
cut
if the slave fails queries that the master eats just
fine? The data shouldn't get out of sync. For example due to the
recent stricter type-casting changes.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
in other queries as well, so it's likely in the cache.
I guess that could make using that index and scan through the results
faster than reading the new index from disk.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
is logged.
I'm confused. How to stop the error?
You don't happen to have any functions that use varchar(20) in their
arguments or for local variables? I'm not sure they'd cause the shown
error, but I expect them to.
Alban Hertroys
--
If you can't see the forest for the trees,
cut
mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4980a309747032541118883!
--
Sent via
On Jan 29, 2009, at 1:35 AM, Phoenix Kiula wrote:
On Thu, Jan 29, 2009 at 2:25 AM, Alban Hertroys
dal...@solfertje.student.utwente.nl wrote:
Ah I see, that's the original query and its plan again, not the one
after
implementing those triggers! You had me scratching my head for a
bit
-1 then null else
fee end ) );
anything wrong with create unique index foobar on foo where fee -1 ?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,497f50e9747031810420427!
--
Sent via pgsql-general mailing list
are to
determine those counts. If those counts are generally very low the
benefit will probably be minimal.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,497f5466747032672819277!
--
Sent via pgsql-general mailing
for the new values and add a
constraint to that, deprecating (or even dropping) the old column from
your design. Don't forget to vacuum afterwards.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,497f5540747032091416566
verify unfortunately.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,497f5aa8747035160810079!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
somewhere... You
might be hitting that with 16MB queries.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,497af707747031347810546!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
violation!
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,49157dd89507271520953!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Aug 22, 2008, at 9:45 AM, Ivan Sergio Borgonovo wrote:
On Fri, 22 Aug 2008 08:48:30 +0200
Alban Hertroys [EMAIL PROTECTED] wrote:
Is it going to make things faster if I:
delete from s;
reindex table s;
Why do you think this step would help you any? There's no index on
p to begin
the start
sequence ID to MAX() + 1?
DELETEs don't use your sequence so will not exhaust it. In practice
only INSERTs do. I saw you mention sequences in combination with
DELETEs a few times, just making sure you're not confused ;)
Alban Hertroys
--
If you can't see the forest for the trees
likely be slower.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,48ae6140243481364815068!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
this is for compatibility
with an other database?
Why use status IN (0, 1) instead of more descriptive keys? Is it even
constrained this way, or could arbitrary numbers end up as status
(say 99) and if so, what happens to those messages?
Alban Hertroys
--
If you can't see the forest
.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4895b34b243488085013917!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
a reference to the toast table somehow)?
Is that data-file on a mirror where one part of the mirror may be
mirroring a bad sector over the good one on the other drive(s)?
I may be talking nonsense, I'm no Tom Lane, but I know a fair share
about postgres ;)
Regards,
Alban Hertroys
--
If you
.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4850140f927661409586227!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
NOTICE: achar is RpS
NOTICE: achar is RhS
NOTICE: achar is R S
find_next_delim
-
6
(1 row)
WHY find a match on the space???
Thanks!
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
'
GROUP BY fips, small.geom, small.name
HAVING SUM(huge.value) 500;
Guessing from your performance problem you may not have an index on
huge.fips? And did you vacuum/analyse those tables anytime recently?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,483c430d927661540552177!
--
Sent via pgsql-general mailing list (pgsql-general
On May 21, 2008, at 7:36 PM, finecur wrote:
select * from my_flexible_sql_function('select * from employee where
dep ='Eng'')
You need to escape that string like 'select * from employee where dep
=''Eng'' '
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
correctly
(two records).
That looks like a bug in 8.1.
So the question is: what has changed from 8.1 to 8.2?
I think a bug was fixed ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,482dbc5e927668957138674!
--
Sent
On May 16, 2008, at 6:54 PM, Alban Hertroys wrote:
development= select b, coalesce( (b in (1, null))::text, 'NULL')
from test;
b | coalesce
---+--
1 | true
2 | NULL
| NULL
(3 rows)
Just remembered a nice option from psql that doesn't quite clutter my
example as much
801 - 900 of 1292 matches
Mail list logo
