n into problems with that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
IG5.TXT as before, with the addition of those seven extra
characters from CP950.TXT.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Heikki Linnakangas wrote:
張桂賢 Roger Chang wrote:
There is authoritative source for the Big5 encoding, but don't believe
that do help
http://www.cns11643.gov.tw/AIDB/encodings_en.do
Skip the historical mess already done. we should focus on reality?
brief events according time
compliant
with CP950, since few years ago.
Ok, so Windows codepage 950 has those 7 characters, but not the other
ETEN extended chars. I think that's a good enough reason to add those 7
chars; we have 'win950' as an alias for big5 anyway.
I'll go add those characters.
--
t all the other characters in the
ETEN extension?
Is there some authoritative source for the Big5 encoding, to look these
things up?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
syslogFile) this is
causing a race condition due to an error in the way we are using the related
critical section.
Thanks, committed. I hope this helps with Ati's problems.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
Sent via pgsql-bugs mailing list (pgsql
sql;
SELECT foofunc();
Gives error:
ERROR: invalid input syntax for integer: "(1)"
CONTEXT: PL/pgSQL function "foofunc" line 6 at SQL statement
Surely assigning a value of btype to a variable of the same type should
always work..
--
Heikki Linnakangas
EnterpriseDB
transaction is in process. The session and any
transactions would remain active.
See statement_timeout.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
to know if the string after "@" is a
valid hostname, we can stop the recursion as soon as we find out that
it's not. The attached patch does that.
Teodor, does this look OK to you?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/tsear
Tom Lane wrote:
Heikki Linnakangas writes:
If we go down that path, how far do we go? We also know that two enums
are never binary-compatible, right? Composite type and a user-defined
base type? Hardly, unless you're doing something very hacky...
Disallowing binary casts when any comp
e database effectively
unavailable.
However, in almost all cases, there is no need for such relaxing of limits
to require a table rewrite.
While this isn't a bug, it's a reasonable feature request. I've added
this to the TODO page: http://wiki.postgresql.org/wiki/Todo#ALTER
Patches
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Although this qualifies as pilot error (superusers are expected to know
what they're doing), should we attempt to prevent the case?
We can't detect binary-incompatibility in general, so I presume you
meant just for t
Tom Lane wrote:
Heikki Linnakangas writes:
Oleg wrote:
CREATE CAST (tmp_table AS composite_ad_texts)
WITHOUT FUNCTION AS ASSIGNMENT;
"WITHOUT FUNCTION" can only be used when both types are binary
compatible. You might think that two composite types with the same
fields are, b
composite type in
the records.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
an insertstatement
is called after the functioncalls.
Well, others might expect the opposite, like existing applications. Want
to suggest wording for the documentation?
To get the id of the row inserted, use INSERT RETURNING. Or currval('bla2').
--
Heikki Linnakangas
Enterpris
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
I wonder how ugly it would be to try to suppress encoding
conversion as well?
The error message might contain user data, which might contain non-ASCII
characters. Or maybe not, but it seems like a shaky assumption to make.
The
Tom Lane wrote:
Heikki Linnakangas writes:
When the conversion function doesn't work, any attempt to send any text
to the client will fail.
Ah, now I remember: we arranged to short-circuit translation of the
error message when we were in this situation. But it will still get
passed th
Tom Lane wrote:
Heikki Linnakangas writes:
I think we should instead try to break the PANIC cycle. If we exceed
ERRORDATA_STACK_SIZE, and we're already PANICing, we should just die
immediately instead of throwing another PANIC about exceeding the stack
size. The attached patch does that
dump from one encoding to
another.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
conversion function with a empty string, to
check that it is in fact capable of doing the conversion. See 2nd
attached patch. This is a usability improvement too, as you
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/utils/error/elog.c b/src/backend/ut
gly.
Thanks, committed.
But I wonder, why does plpgsql debugger even try to display those
variables after the exception block? I'm not familiar with the tool; I'm
guessing that it just displays all variables, regardless of scope.
--
Heikki Linnakangas
EnterpriseDB http://www.enterp
ries. Since you upgraded to 8.3.6,
have you restarted PostgreSQL? What does "SELECT version()" say?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.post
errors when both server and pgAdmin 8.3.6.
On a my opinion, pgAdmin must deny vacuum/analyze on inconsistent version.
That should work just fine. What errors are you getting?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs
. I appreciate
your help.
Umm, yes: the user manual.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
toruvinn wrote:
On Mon, 16 Feb 2009 10:37:27 +0100, Heikki Linnakangas
wrote:
You can read the value returned by currval into a host language
variable and send it back as a ?.
Wouldn't it be possible to do UPDATE booking_entries SET date = ? where
id = (SELECT currval('booking_entr
a ?.
Or you can create a wrapper function around currval that's marked as
stable instead of volatile, to hide currval's volatility. However, that
would amount to lying to the optimizer and you might get some surprising
results with more complex queries, so I wouldn't recommend i
RT TRANSACTION command.
You could use -t, or add a COMMIT after the "set search_path".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Konstantin wrote:
* Tom Lane [Thu, 12 Feb 2009 10:54:34 -0500]:
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired
a
RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening fo
Konstantin wrote:
* Heikki Linnakangas [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I e
86-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
20060404 (Red Hat 3.4.6-9)
I can reproduce this on CVS HEAD too. I'll try to figure out what's
going on..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresq
Tom Lane wrote:
Heikki Linnakangas writes:
Dave Page wrote:
It's possible to set a per-database connection limit of < -1, which seems bogus:
Yeah. That's simple to fix, but I'm having trouble wordsmithing the
error message. This is what I came up with:
Why does it n
to...@tuxteam.de wrote:
On Mon, Jan 26, 2009 at 02:26:05PM +0200, Heikki Linnakangas wrote:
Dave Page wrote:
It's possible to set a per-database connection limit of < -1, which seems
bogus:
Yeah. That's simple to fix, but I'm having trouble wordsmithing the error
message. T
nce it doesn't cause any
actual problems. We'd just risk breaking people's scripts that use
-999 to mean "no limit". (they will be broken when they upgrade to 8.4
anyway, of course, but that's fine)
--
Heikki Linnakangas
EnterpriseDB http://www.en
Fujii Masao wrote:
On Thu, Jan 15, 2009 at 9:09 PM, Heikki Linnakangas
wrote:
1. The proposed patch would remove the "+ 1". Seems like an unnecessary API
change, and I don't recall any reason why the new definition would be
better.
My patch doesn't change the return val
ithin the
just-completed transaction log file.
If there has been no transaction log activity since the last
transaction log switch,
pg_switch_xlog does nothing and returns the *start*
location
of the transaction log file *currently in use*.
--
Heikki Linnakangas
EnterpriseDB http
think that we should
also backport.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
[ Attachment, skipping... ]
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
Pavel Stehule wrote:
My first patch expected so RETURN QUERY is final statement, so I don't
solve FOUND variable, but Heikki changed this behave.
Me? I don't recall doing anything related to this.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
d could yield unexpected results. In the context of an ISO year, the concept of a 'month' or 'day of month' has no meaning. In the context of a Gregorian year, the ISO week has no meaning. Users should take care to keep Gregorian and ISO date specifications separate.
--
Heikki
age header error also appeared under its version 8.3.1
with OS FreeBSD 7.0 :
That sounds very random. I suspect bad hardware, bad RAM perhaps. On how
many computers does the error occur?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (
t assuming some overhead that's completely insignificant
in the big scheme of things.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Y);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"foo_pkey" for table "foo"
CREATE TABLE
postgres=# CREATE INDEX i_foo ON foo (id);
CREATE INDEX
postgres=#
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing l
at's wrong with bytea?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
PostgreSQL error codes are not as unique as the error messages.
If you don't like translated error messages, you could just set
lc_messages to en_US in your postgresql.conf.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
tgres code?
There's no named individuals, just the community in general.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ave solved this, but he didn't get around to finish it for 8.4.
Maybe 8.5...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
experienced sudden power
loss, or operating system crash on these machines? Have you done "kill
-9 postmaster", "pg_ctl stop -m immediate", or similar? PostgreSQL
should recover with no data corruption, of course, but if there's a bug
somewhere, it would help to know wh
x27;2008-11-14 16:00:00','-MM-DD
HH24:MM:SS'),'day');
ERROR: conflicting values for "MM" field in formatting string
DETAIL: This value contradicts a previous setting for the same field type.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprise
s the constant
AutoVacNumSignals is not defined correctly. It should be (AutoVacRebalance +
1).
Yeah, that's clearly a bug. Fixed, thanks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
n't think so. pd_special is the offset to the start of the
special area, so (BLCKSZ - pd_special) is the size of the special area.
However, that max_avail field actually looks like dead code, anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs ma
anonymous wrote:
CLUSTER still does a full page scan although there are 0 dead rows on table.
That's not a bug. Keep in mind that the main purpose of CLUSTER is not
to remove dead tuples, but to reorder the rows.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
e you sure you didn't
have a long-running transaction open that prevented vacuum from working?
Did the heap bloat as well, or just the index?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chang
ds on what language's collation rules you want to
follow. "locale -a" in a shell should list the available options.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to you
FSMs when I
added the FSM vacuum code. Index FSMs need to be vacuumed just like the
heap FSM. Fixed, thanks for the report.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
in evince, please report to the Evince team.
It's possible that there's something wrong in the PDF that triggers that
bug in evince, but an assertion failure shouldn't nevertheless happen.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs m
k to query */
+ context->inserted_sublink = true;
+ /* fall through to copy the expr normally */
+ }
return expression_tree_mutator(node, ResolveNew_mutator,
(void *)
context);
}
--
_BINARY 0
#define PG_BINARY_A "a"
#define PG_BINARY_R "r"
#define PG_BINARY_W "w"
#endif
I don't see anything wrong with the patch, but I wonder if there's more
open() calls that need the same treatment? Like the one in
pg_resetxlog.c/ReadControlFile().
--
You can change the way a conversion is done with CREATE/DROP CONVERSION.
That's why it can't be IMMUTABLE.
(I doubt any sane person would actually do that, but that's another debate)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mail
prepared transactions, aka two-phase commit, or did you mean prepared
statements?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
kely a bug. Please use the pgsql-general mailing list
next time.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
as client_encoding if you need to,
even if the server uses UTF-8.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[EMAIL PROTECTED] wrote:
Is there guide to compile PG?
http://www.postgresql.org/docs/8.3/interactive/install-win32.html
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
We should use range_table_walker, which knows how to descend into all
kinds of RTEs...
Yeah, I had been thinking of that but didn't see an easy way to apply
it; of course the answer is to use Increment
ut I'm
not sure they couldn't either.
Hmm. Maybe through a rewrite or something?
We should use range_table_walker, which knows how to descend into all
kinds of RTEs...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/optimizer
I didn't notice because I was testing without assertions.
Hmm, do we need the copyObject() call for non-subquery RTEs? I'm
guessing no, because they're not modified.
--
Heikki Linnakangas
EnterpriseDB http://www.ente
Heikki Linnakangas wrote:
Tom Lane wrote:
Seriously, I think what this shows is that piecemeal pullup is wrong in
principle, and that the right approach is always to concat the
subquery's rtable in toto to the upper level, and then go from there on
adjusting varnos. Do you want to look
mean like pull_up_simple_subquery() does? Yeah, I can try that. This
isn't really something I'm familiar with, but it's great exercise :-).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
the rest of the logic to pull up UNION ALL subqueries, in
8.2, and has been broken ever since.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
er not possible or we don't care, because that
can happen without the patch just as well.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/optimizer/prep/prepjointree.c
===
RCS file: /home
Heikki Linnakangas wrote:
Brendan O'Shea wrote:
There appears to be a bug in the way that permissions are determined for
views that contain "UNION ALL" in their definition.
There is a simple test case to reproduce the bug.
1) As a superuser create the following object
and
higher, 8.1 seems to work. I'll dig deeper tomorrow, unless someone else
beats me to it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
As Tom pointed out, the order depends on the locale.
Blanco, Jose wrote:
So is there no way to make oder by work with names?
-Original Message-
From: Heikki Linnakangas [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2008 3:00 AM
To: Blanco, Jose
Cc: pgsql-bugs@postgresql.org
Heikki Linnakangas wrote:
Unlike on some systems, in PostgreSQL "ORDER BY 1" means order by the
constant value "1", not the first column. Try "ORDER BY name".
Oh, that's of course not correct at all. "ORDER BY 1" does indeed mean
order by f
systems, in PostgreSQL "ORDER BY 1" means order by the
constant value "1", not the first column. Try "ORDER BY name".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
ER BY popularity" doesn't force any particular
order. This is effectively the same as if there was no ORDER BY at all;
the database is free to return the rows in any random order it wishes.
You can use ORDER BY popularity, name DESC for the order you were
expecting..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
& 255::int8) || ''.'' ||
(($1>>16) & 255::int8) || ''.'' ||
(($1>>8) & 255::int8) || ''.'' ||
($1 & 255::int8) as result
'
LANGUAGE 'SQL';
You can create the cast yourself if you want to, see CREATE CAST.
iling list, probably pgsql-general. This list is for bug reports only.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t;postgres" database. You could
still recreate it from the command line with psql:
psql template1 -c "DROP DATABASE postgres"
psql template1 -c "CREATE DATABASE postgres"
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mail
drop auto-cascades to index
eventregistration_pkey
2008-06-05 14:28:58 IST DEBUG: drop auto-cascades to constraint
fk490d8536643b1db on table eventregistration
2008-06-05 14:28:58 IST ERROR: cache lookup failed for relation 630146
2008-06-05 14:28:58 IST STATEMENT: drop table eventregistration;
along with the error
message, so that we can get a better idea of what you're doing. What
happened when it stopped working?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscri
ug. Use "ALTER TABLE mytable ALTER mycolumn TYPE text
USING ...".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ent
version is 8.0.3, there is no problem, I don't know why, does it the
configuration problem?
Please post the exact output you're getting in both cases.
What version is the server?
You should upgrade to the latest minor version, which is 8.1.11 for the
8.1 series, and 8.0.15 fo
eing in
use/listening. I also tried changing the port in pgadmin to something else
like 5050 but same error.
Google suggests that errcode 1069 means login problems. Make sure the
postgres user account is set up properly, the "change password at next
login" checkbox is not checked
of the ossp-uuid
library to me.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
wColumn"='something'. If that's what happened, I'd suggest dropping
and recreating the column in all-lowercase.
If this didn't help, please post the output of the "SELECT *" verbatim.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
is 64 bytes, but the 64th byte is reserved for the
null-terminator, so the string stored can be at most 63 bytes long.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
t
deterministic because in about 80% of request times the result is correct.
Do you get the same results if you run the "SELECT * FROM
benutzer_mit_rolle_vw" query directly from psql? What does EXPLAIN
ANALYZE say?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.co
e created the database with WIN1252 encoding instead to
begin with.
I think you can fix that by dumping the database in LATIN1 encoding,
modifying "client_encoding" line in the dump file to 'WIN1252', and
importing it back.
--
Heikki Linnakangas
EnterpriseDB http://www.
don't use AttrNumber
in any of the on-disk structs. Though you still couldn't have more than
MaxHeapAttributeNumber (1600) attributes in a table or
MaxTupleAttributeNumber (1664) in a result set or intermediate tuples,
like the output of a sort node, at least you coul
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
On second thought, expanding AttrNumber to int32, wholesale, might not
be a good idea,
No, it wouldn't. For one thing it'd be a protocol break --- column
numbers are int16 ---
I wasn't planning to c
with VFP9.
When I execute "SELECT FROM Customers", server crash with fatal error.
Before versions does not crashed when sintax error.
Please post the exact and complete error message you're getting.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent vi
-hackers/2008-01/msg00268.php
In a nutshell, it's just not safe to access a view or function owned by
a user you don't trust. :-(
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
e with WEST, but it seems
quite likely. We do have the abbreviation WETDST for that, though.
I found a way to *hack* the solution by copying the file Portugal to WEST in
share/timezones
No need for such hacks, see:
http://www.postgresql.org/docs/8.3/interactive/datetime-config-files.html
CC'd so that others can help.
-Ursprüngliche Nachricht-
Von: Heikki Linnakangas [mailto:[EMAIL PROTECTED] Im Auftrag von Heikki
Linnakangas
Gesendet: Montag, 31. März 2008 14:58
An: Ceschia, Marcello
Cc: pgsql-bugs@postgresql.org
Betreff: Re: [BUGS] BUG #4070: Join more then ~15
Marcello Ceschia wrote:
If you need more information, contact me I can send some example data.
Yes, we need more information. Please send a minimal test case with
CREATE TABLE statements and data required to reproduce the problem.
--
Heikki Linnakangas
EnterpriseDB http
fixes.
What's our policy wrt. back-patching doc changes? This seems applicable
to older versions as well, but do we do that?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscrip
t for sure many times before we reach beta stage.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Sergey Burladyan wrote:
Thursday 20 March 2008 01:16:34 Heikki Linnakangas:
Here's a patch that does the conversion in the other direction as well.
As I'm not too familiar with cyrillic, can you double-check that this
works? I tested it using the convert() function between different
Heikki Linnakangas wrote:
Sergey Burladyan wrote:
src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c
does not have cyrillic letter 'IO' in ISO-8859-5 to mule internal code
translation table (function iso2mic(const unsigned char *l, unsigned
char *p, int len)
quot;YO" is in an odd place in the table, compared to all
other cyrillic characters. Perhaps that's why it was missed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ut Native Language
Support support (see --enable-nls configure option).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
401 - 500 of 661 matches
Mail list logo
