fire
and all those other tables need to be updated too.
> However, if that fails, the table is dead. You will have to reload it from
> backup.
Right, and that goes for all the affected tables.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing l
schemas in sync during
cutover period).
This second approach isn't faster, it's hard on I/O and disk space,
but it keeps you up and you can do the changes at a leisurely pace.
Just make sure you have the I/O and space before you do it :)
Hope that helps,
A
--
Andrew Sullivan
a...@crankyca
ion of some of the key contributors to Postgres, who
appear to work mostly in a mode where email makes things easy for them
and logging into a new forum tool makes things harder.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postg
al one -- that requires no trades.
Distributing data reliably with ACID semantics and no data loss or
corruption or loss in write throughput is not possible, at least
today. You have to pick which poison you want :)
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general m
to some other
place later, and it'd suck if the transaction failed half way through
because it turns out there's nowhere to put the data I've just staged.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ason we're still using 9.2.
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
m. But one has to
face the critique in its own terms.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
mpatibility historically was the basis for something
becoming a major version upgrade. (I can recall a couple bugs where
you had to tickle the catalogues, so it's not exactly true that
they're never incompatible, but it's incredibly rare.)
Best regards,
A
--
Andrew Sullivan
a...@crankycanu
27;t deserve while
> they treat customers and employees with similar levels of arrogance.
Nothin' for nothin', but I don't think it helps Postgres to attack
others' business plans -- whatever one thinks of them -- as part of an
argument about why Postgres is the right tool fo
this mysql2pgsql conversion rather than N dedicated small teams for
> every mysql client out there.
…I don't think anyone is telling you, "Don't build this." You should
do what you like with your time :)
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailin
s to MySQL, MySQL always wins, what you teach them is
"Postgres performance sucks."
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
re's something that we're going to have to accept, however,
and that's that there are way more application coders than there are
people who really get database systems. Fixing this problem requires
years of efforts.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent vi
t I've been in the
sort of long, boring speculative conversation that could have been
shut down quickly with this kind of data.)
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://ww
hors intended. Doesn't matter for
these purposes! :)
[2] Apparently, Marshall McLuhan didn't say this; instead, his tribune
John Culkin, SJ said it. It's still an excellent point, whoever made it.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
card number gets lost in an
eventually-consistent system, and people suddenly understand
viscerally why transactions semantics are so hard.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs
receive a message that data is committed before any replication of the
data has commenced," would that help?
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
fork. But …
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/postgresql/Driver
… since it can't find the driver, I'd bet that your classpath doesn't
contain /opt/postgresplus/edbmtk/lib.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
to recover after a restart.
It may not be the hardware. Depending on how vmware is configured, it
could just be a setting. Also, something in the OP's message made me
think that this was _actually_ a network-attached disk, which can also
have such problems. (But in general, I agree.)
A
at can be done about it?
You may end up taking an outage in effect, because you need to compact
them at least once. If you can flip to a replica, that is the easiest
way to fix it.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.o
at stuff about what the IETF does some
while ago. There is definitely more than one way to do this.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
that you actually want to fail over.
I've seen an awful lot of people want automatic failover who also
can't afford for the already-committed transactions on the master to
be lost. Unless you're running synchronous, be sure you have the
workload that can actually accept lost w
tended in the generic sense. I apologise in case
that wasn't clear.
> It is the perceived intention of what one says that is important, not what
> one actually says!
I think that is perhaps a false dichotomy. But I also think I have
said enough on this topic, so I shall stop now.
B
an we can do something about it by writing down rules.
Still, the exercise of writing down rules may help to notice things
one wouldn't say to a friend. And I hope we're all friends here.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list
children of slaves.
If someone did that, it would fall under (2), no? (I note that a
recent RFC, of which I am a co-author, about DNS terminology did say
that "primary" and "secondary" were to be preferred over "master" and
"slave". I didn't personally
urage those who think there is a problem to
be solved to make a scratch proposal and see whether it flies. It's
always easier to discuss a concrete proposal than to try to figure out
whether something is a good idea in the abstract. The shorter and
easier to understand the proposal is, I
losing the
shell so that the session hangs around). Eventually, the Postgres
backend will try to talk to the session and discover it isn't there,
and you'll get a termination logged (assuming you have loging turned
up that high).
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent
e you can! There are also some firms that can help with
migration if you like.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
uditor, this might be enough
to satisfy the condition.
Also, of course, there is the application_name (string) parameter. In
principle, you ought to be able to filter on this. Again, won't help
you if your application login is somehow compromised.
I agree that all of this depends on logging
al risk to be
mitigated is. It might, sure. The security profiler would still need
to make a list of this fact and then ask how countermeasures mitigate
it.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresq
metimes people delete data from a system because
it's been archived somewhere else or something like that -- not all
databases have the totality of all the relevant data in them, but can
often represent just "current" data.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
ssibly be exfiltrated,
you need to know the state of all of it.
For realistic cases, I expect that deleted data is usually more
important than updated data. But a threat modeller needs to
understand all these variables anyway.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-g
m MySQL already.
Consistency and rigour are the changes ;-)
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I. But do consider
trying out the command line. You'll be surprised at the power you get
once the initial learning curve is over.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
h
hacks, but if you need a bugfix prior to a real solution
they'd give you a path.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
lly sure why you think the manual is misleading.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ut you asked what was behind the design
decision and I told you. But in general, the experience seems to be
that triggers are easier to get right (novice or no, _pace_ section
38.7).
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-genera
e all the
data in the table. I don't know what rewriting such a query would
mean.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
st, I
found that to be useful when talking to Oracle partisans.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
emed developer claimed something and
maybe should have relinquished sooner given his workload. That
happens; nobody's perfect. It's frustrating, but this is not the only
community to have had that issue (cf. Linux kernel, for an
approximately infinite series of examples of this). I am not su
onvention.
This case is no different.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ty's time with crowdsourced editing of job
postings is in any way appropriate for the pgsql-general list.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql
b from the
old machine and restore locally, you could do
pg_dump -U postgres -h 192.0.2.1 -C egdb | psql -U postgres
I recommend reading the pg_dump (and if you like, pg_dumpall) manuals
before proceeding.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list
systems to move all the data from one to the
other. Depending on your uptime requirements and the size of the
database, this approach can either be a life saver or a total waste of
time and will to live. More often the latter, please be aware.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sen
ring and are
> consuming by far the most disk space (still somewhat expensive on SSD)!
This doesn't actually solve your problem, but you could mitigate the
cost by putting those tables on spinning-rust disks using tablespaces
or symlinks or whatever.
Best regards,
A
--
Andrew Sullivan
corruption fixes since 9.0.4. You should always try to
stay on the latest minor release of your version of Postgres.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.p
ure it does the thing requested in this case.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
don't know
whether Bucardo or Londiste (two alternative systems that work on
roughly the same principle) have this functionality, but I kind of
doubt it since both were designed to get rid of several of the
complexities that Slony presented. (Slony had all those complexities
because it w
s dramatically reduced the number of such
cases. Some convenience was lost (I still get tripped up from time to
time, but I'm not doing Pg work every day), but the overall
reliability of things was increased. So I'd say it's probably not a
bug.
A
--
Andrew Sullivan
a...@crankyc
SAVEPOINT foo;
Q2;
if error then
ROLLBACK;
These both work. The problem is, I think, that you have different
rules for "when Q2 fails", and without knowing your exact
circumstances I suspect we can't say much more. Indeed, however, it
sounds to me like you think these are in the same wor
that many people are using for
IDNA2008:
<https://gitorious.org/libidn2/libidn2/source/0d6b5c0a9f1e4a9742c5ce32b6241afb4910cae1:>
It's GPLv3, though, which brings its own issues.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@
under IDNA2008.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ode encoded label, no leading or trailing
> hyphens
> on a label, etc.
You seem to want a bunch of label constraints, not all of which are
related to IDNA. I think it would be better to break these up into a
small number of functions. As it happens, I have a colleague at Dyn
who I think
A2003 and then
punycode-decoding it doesn't always result in the same label. See my
other message.
Did I mention that IDNA is a mess?
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
self with those time changes. It makes debugging easier,
particularly because the time change only happens twice a year so
nobody _ever_ thinks of it when troubleshooting.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql
On Tue, Aug 19, 2014 at 07:41:00PM +0530, Sameer Thakur wrote:
> We are thinking of building our own version of Oracle's sysdate, in
> the form of PostgreSQL extension.
I thought that was the point of the statement_timestamp() function?
A
--
Andrew Sullivan
a...@crankycanuck.ca
-
r is
it that you are somehow trying to prove that what you have on the
target (backup) machine is in fact production-ready? I guess I don't
really understand what you are trying to do.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresq
On Wed, Jun 25, 2014 at 03:37:11PM +0100, James Le Cuirot wrote:
> Sorry, you're missing the point. I'm trying not to alter the existing
> behaviour of the Chef database cookbook
Ah, got it. Sorry, I'm clueless. No, I don't think I have a
suggestion, then.
ll
> not have the desired effects."
Hmm. I've _used_ transactions in such files, I'm pretty sure. You
don't need the --single-transaction setting for this, just do the
BEGIN; and COMMIT; yourself.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general ma
ation running at the same
time), what you really want to do us use the schema (or namespace)
support in Postgres. Be careful with this, however, as it is easy to
make a system so convoluted that nobody can understand it.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general maili
probably don't need a trigger, just put that in your
query.
Are you sure you want this without time zone? In my experience,
almost every time people think they want "without time zone" they
actually don't.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-gen
l you were actually
using. If it were me, I'd say yes.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, Apr 08, 2014 at 12:46:37AM +0200, Stefan Keller wrote:
> Hi Andrew
>
> 2014-04-07 23:37 GMT+02:00 Andrew Sullivan wrote:
> > (1) this has been discussed many times in the past (...)
>
> Can you point me to one of these discussions?
>
> Actually, I browsed once
e if someone else did this
work;" and (3) there _are_ several in-memory-only databases on the
market, including free-software ones, so it isn't clear what Postgres
would contribute, especially since its basic design isn't obviously
amenable to this sort of use.
Best regards,
A
--
A
ic workloads, but in more recent releases (9.1.x certainly
qualifies) you are much better to tune autovacuum.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.post
think any reason why not.
(ISTR when I did this in the past we didn't have window functions, so
I simulated it another way.)
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
lts, so you don't count everything needlessly
in case the user just uses the first page, which IME happens a lot).
Note that even Google doesn't give you an accurate number -- they just
say "about ten trillion" or whatever.
Hope that's useful,
A
--
Andrew Sullivan
a..
tement.
Why don't you put a DO INSTEAD trigger or rule (I'd suggest the
former) when you put in a 0 to do nextval() instead on the sequence
for the column?
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.o
ws in an unpredictable order is an
excellent way to run into trouble, and long-running transactions are a
major source of these problems. Without a more detailed report about
what is going on in the present case, I don't think it's going to be
possible to diagnose better than has been
chain of locks such that it doesn't look
like a deadlock to the detector, but the lock chain is such that no
query will ever be able to release.)
I suspect you need to get your locks in a consistent order or you'll
continue to have this problem.
A
--
Andrew Sullivan
a...@cranky
atically in the face of concurrency.
It _is_ doing the appropriate thing, though: this is SQL. The rows
aren't ordered unless you tell them to be.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make change
t; the results based on a secondary column that I know the order of. This
> works, but seems clunky, so I'm wondering if there's a nicer way.
This is probably what I'd do, assuming that "further processing" isn't
more data transformation. If it _is_, then I'd
, NULL, NULL, NULL, NULL, NULL, NULL, false, false);
>
>
>
> CONFIDENTIALITY NOTICE
> The contents of and attachments to this e-mail are intended for the addressee
> only, and may contain the confidential
> information of Argility (Proprietary) Limited and/or its subsidiaries. Any
is,
really.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
onnection time.
That's going to yield the most predictable behaviour for the users, I suspect.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
x27;re used to
certain other RDBMSes, this mode of functioning will be unusual, but
that really is how it works.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
client connects.
The timestamps in the server are not actually "in" a time zone.
They're all stored as UTC, and the display is altered according to
what your time zone settings are at the time of query.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sen
time as
> per timezone.
Try issuing SET TimeZone commands. I think you'll find that the
client can set whatever time zone it wants.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
-DEBUG-statements-from-psql-commends-tp5791250.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpr
rt of the function. This is
strange to people because when you're developing it's normal to think
of functionname(args) as the thing you're changing, but in a system
that allows overloading like Postgres that's not really true for
production.
A
--
Andrew Sullivan
a...@crankycan
tgres actually
gives you the power to adjust its behaviour according to your use
case, and there's no reason not to use that when appropriate.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
m, it
turns out that one of the brilliant developers has not only thought of
it, but has fixed it while you weren't looking. In a large-scale
generalized way that doesn't have whirling knives sticking out of it.
(Yes, I have been using some other DBMSes recently, and no, I don'
if the developers could write code that read minds, they'd be
working on more profitable enterprises ;-)
Best,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
be exactly right.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ausing any change in pg_dump output.
Oh. You need to up your autovacuum settings for the system catalog
tables. I built a system that did this sort of thing. If your
autovacuum settings are correct, this will stabilize.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-gen
hem or whatever (I presume they're
not going away because your connection is long lived)? They're
supposed to be temporary, after all: cheap and disposable.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
see it, it's always obvious what you've done, in
my experience (and completely mystifying before that, unfortunately).
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
(which you don't show us), you're chewing through
a lot of sort_mem. Remember that sort_mem is allocated _per sort_, so
it could be that a lot of these allocations fit fine in real memory if
only 8 processes are doing it; but if 10 do, you pass your threshold
for physical memory
On Fri, Jan 03, 2014 at 10:00:42AM -0500, Tom Lane wrote:
> know the end-to-end MTU size with any reliability.
Well, you could try PMTU discovery, though I agree that it's not
great. It also seems pretty low-level for something like the DBMS to
be doing.
A
--
Andrew Su
o be your friend.
Anyway, those are two ways I've done this sort of thing in the past.
Best regards,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
.@arin.net if you experience any issues.
- End forwarded message -
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
h CI
and lower() all the input text during searches, in order to avoid any
work on the schema. Bit of a kludge, though.
Best,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.
ds: it increases code complexity and
dramatically increases the risk that one part of the code will be
altered without correctly altering the other part. What is
inconvenient for you incereases the reliability of Postgres, and I
humbly suggest that your evaluation of convenience in this
then you can look at what the
settings were when you have a crashed or otherwise troublesome system.
Best,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
eed TLS/SSL anyway. I guess I'd respond that you could use TLS
anyway because it would help in case of a network compromise.)
Best,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
auses trouble with UTF-8 encoding. I liked your conversion
suggestion, however, in your other mail.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ncoding, but on Windows that isn't true, and 1252 is
_almost_ but not quite Unicode. This bites people generally in
internationalization.)
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
omer", since your
customer certainly is having something done to them.
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ight be a special optimisation of the
Postgres code).
Best,
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ds of program unless they are
designed and sold by IBM, whose product once made my afternoon more
amusing than I wanted by blowing up the data area on fail over not
once, or even twice, but three times. (This was attributed to
operator error, because the operator had dared to run the f
1 - 100 of 733 matches
Mail list logo
