For example you want to define a function for LATIN1 to UNICODE conversion
function would look like:
function_for_LATIN1_to_UTF-8(from_string opaque, to_string opaque, length
integer)
{
:
:
generic_function_using_iconv(from_str, to_str, ISO-8859-1, UTF-8,
I have committed changes enabling new CREATE CONVERSION/DROP
CONVERSION SQL commands. You can issue these SQL commands, but they
just add/remove tuples to/from new system catalog pg_conversion.
Still needs lots of work...
Initdb required.
For those who wishes to try these (currently) useless
On Thu, Jul 11, 2002 at 03:37:49PM +0900, Tatsuo Ishii wrote:
CREATE FUNCTION function_for_LATIN1_to_UTF-8(opaque, opaque, integer)
RETURNS integer;
CREAE CONVERSION myconversion FOR 'LATIN1' TO 'UNICODE' FROM
function_for_LATIN1_to_UTF-8;
Hmm, but it require define
Where/how is describe conversion between encoding id and encoding
name? (I maybe something overlook:-) I expect new encoding system
will extendable and encodings list not will hardcoded like now.
(extendable = add new encoding without PostgreSQL rebuild)
User defined charsets(encodings)
Changing data types probably won't appear. I don't know of anyone
working on it -- and it can be quite a complex issue to get a good
(resource friendly and transaction safe) version.
I'd be happy with a non-resource friendly and non-transaction-safe version
over not having
pg_char_to_encoding() is already in libpq. Or am I missing something?
It works with encoding table (pg_enc2name_tbl) and it's compiled
into backend and client too. It means number of encoding is not possible
change after compilation and you (user) can't add new encoding without
On Thu, Jul 11, 2002 at 05:52:18PM +0900, Tatsuo Ishii wrote:
pg_char_to_encoding() is already in libpq. Or am I missing something?
It works with encoding table (pg_enc2name_tbl) and it's compiled
into backend and client too. It means number of encoding is not possible
change
No, it's not a libpq problem, but more common client/server problem
IMO. It's very hard to share dynamically created object (info)
effectively between client and server.
IMHO dynamic object will keep server and client must ask for wanted
information to server.
I agree with you.
On Wed, 10 Jul 2002, Christopher Browne wrote:
And if there are 20 places that say It's officially spelled
PostgreSQL, but you can _pronounce_ that 'p\O\st-gres', and here's
the MP3 of Bruce saying it, that can cope with the situation nicely.
For the record, the voice on the MP3 isn't Bruce.
IMHO, I believe that the standard should be adhered to if at all possible.
Since Cascade was added, Restrict must be the default is my reading of the
standard.
So that everyone can talk from the same sheet, the 1999 SQL Standard for DROP
TABLE follows:
11.20 drop table statement
Function
How long did it take you to teach him to say PostgreSQL ? :)
Jeff.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Vince Vielhaber
Sent: Thursday, July 11, 2002 6:31 AM
To: Christopher Browne
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] I am being
The estimator only uses effective_cache_size, it never looks at
NBuffers. So shouldn't we add
if (effective_cache_size NBuffers)
{
elog(NOTICE, adjusting effective_cache_size to %d,
NBuffers);
effective_cache_size =
On Sat, 10 Aug 2002, Jeff MacDonald wrote:
How long did it take you to teach him to say PostgreSQL ? :)
Lessee, the conversation went something like this:
Me: I need a wav file of you saying PostgreSQL.
Him: PostgreSQL?
Me: Yeah.
Him: Ok, I'll get it to you later today.
Then after I made
On Thu, 11 Jul 2002, Vince Vielhaber wrote:
On Sat, 10 Aug 2002, Jeff MacDonald wrote:
How long did it take you to teach him to say PostgreSQL ? :)
Lessee, the conversation went something like this:
Me: I need a wav file of you saying PostgreSQL.
Him: PostgreSQL?
Me: Yeah.
Him: Ok,
Manfred Koizar [EMAIL PROTECTED] writes:
The estimator only uses effective_cache_size, it never looks at
NBuffers. So shouldn't we add
if (effective_cache_size NBuffers)
Pretty useless considering that effective_cache_size can be SET on the
fly...
In general, my philosophy has been
On Thu, Jul 11, 2002 at 06:30:48PM +0900, Tatsuo Ishii wrote:
No, it's not a libpq problem, but more common client/server problem
IMO. It's very hard to share dynamically created object (info)
effectively between client and server.
IMHO dynamic object will keep server and client
IMHO basic encoding information like name and id are not problem.
The PQmblen() is big problem. Strange question: is PQmblen() really
needful? I see it's used for result printing, but why backend not
mark size of field (word) to result? If backend good knows size of
data why not send
I can't improve performance on this
query:
SELECTsupplier.name,supplier.addressFROMsupplier,nationWHEREsupplier.suppkey
IN(SELECTpartsupp.suppkeyFROMpartsuppWHEREpartsupp.partkey
IN(SELECTpart.partkeyFROMpartWHEREpart.name
like 'forest%')AND
Bruce Momjian [EMAIL PROTECTED] writes:
Now, if someone wanted to say CASCADE|RESTRICT was
required for DROP _only_ if there is some foreign key references to the
table, I would be OK with that, but that's not what the standard says.
But in fact that is not different from what I propose to
I think that is the proper behavior Tom.
Also I agree with Bruce that this might be an oversight in the standard. That
is why standards evolve. As I write this I am also sending a note to H2 asking
about this very issue. The latest working draft still has this construct.
Dana
-Original
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Now, if someone wanted to say CASCADE|RESTRICT was
required for DROP _only_ if there is some foreign key references to the
table, I would be OK with that, but that's not what the standard says.
But in fact that is not different
On Thu, 2002-07-11 at 11:22, Luis Alberto Amigo Navarro wrote:
I can't improve performance on this query:
Blame Canada!
--
J. R. Nield
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
On Thursday 11 July 2002 12:06, J. R. Nield wrote:
On Thu, 2002-07-11 at 11:22, Luis Alberto Amigo Navarro wrote:
I can't improve performance on this query:
Blame Canada!
Whatever ...
How's that silver medal down there in the states?
;-)
---(end of
What should be the permissions required to create a cast?
Currently, it's approximately first come, first serve. You probably need
to have execute privilege on the function, but that is the least concern.
With no permissions required on either the source or the target type, it's
easy to
On Thu, 2002-07-11 at 17:22, Luis Alberto Amigo Navarro wrote:
I can't improve performance on this query:
You could try rewriting the IN's into = joins
or even use explicit INNER JOIN syntax to force certain plans
with a select inside another and depending on value of partsupp.partkey
it is
Mac OS X:
postgres% psql --version
psql (PostgreSQL) 7.2.1
contains support for: multibyte
LEDEV=# create table test1 (foo varchar(5));
CREATE
LEDEV=# create table test2 (foo char(5));
CREATE
LEDEV=# insert into test2 (foo) values ('S');
INSERT 3724249 1
LEDEV=# insert into test1 (foo) values
On Thu, 2002-07-11 at 17:22, Luis Alberto Amigo Navarro wrote:
I can't improve performance on this query:
You may also want to rewrite
lineitem.shipdate(('1994-01-01')::DATE+('1 year')::INTERVAL)::DATE
into
lineitem.shipdate(('1995-01-01')::DATE
if you can, as probably the optimiser will
On Thu, 2002-07-11 at 17:22, Luis Alberto Amigo Navarro wrote:
I can't improve performance on this query:
This _may_ work.
SELECT
supplier.name,
supplier.address
FROM
supplier,
nation,
WHERE supplier.suppkey IN (
SELECT part.partkey
FROM part
WHERE part.name
Florian, I haven't seen this patch yet. Did you send it in?
---
Florian Helmberger wrote:
Hi.
Huh? isalpha() *is* locale-aware according to the ANSI C spec.
For instance, the attached test program finds 52 alpha
In reply to Hannu Krosing
Iavor Raytchev wrote:
How hard will the migration from MySQLzilla to PostgreSQLzilla be ?
Is this a rhetoric question?
I have no idea.
A posting I saw (by one of the Bugzilla guys, I think) required something to
be done in PostgreSQL before they can migrate
With all this dependency stuff, what happens with the ALTER TABLE / DROP NOT
NULL syntax we came up with?
Maybe we should allow RESTRICT/CASCADE on that syntax and if restrict is
specified, you can't drop it if a primary key depends on it and if cascade
is specified it will drop the primary
Yeah, I've got it Bruce - I still haven't had time to look into it and I
really don't know what to do about the backward compatibility issue. How do
I set up 2 identically named C functions with different parameter lists?
Chris
-Original Message-
From: Bruce Momjian [mailto:[EMAIL
The Bugzilla project plans to support PostgreSQL in one of their future
releases, but this requires functionality in PostgreSQL, that is not
even scheduled for 7.3. So the availability of a supported PostgreSQL
port of Bugzilla is unpredictable at this time.
I think he said that they needed
Christopher Kings-Lynne wrote:
The Bugzilla project plans to support PostgreSQL in one of their future
releases, but this requires functionality in PostgreSQL, that is not
even scheduled for 7.3. So the availability of a supported PostgreSQL
port of Bugzilla is unpredictable at this
Jan Wieck wrote:
Christopher Kings-Lynne wrote:
The Bugzilla project plans to support PostgreSQL in one of their future
releases, but this requires functionality in PostgreSQL, that is not
even scheduled for 7.3. So the availability of a supported PostgreSQL
port of Bugzilla is
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
With all this dependency stuff, what happens with the ALTER TABLE / DROP NOT
NULL syntax we came up with?
Nothing, AFAICS. NOT NULL doesn't have any dependency implications.
Also, when talking about whether or not the index supporting a
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
With all this dependency stuff, what happens with the ALTER
TABLE / DROP NOT
NULL syntax we came up with?
Nothing, AFAICS. NOT NULL doesn't have any dependency implications.
What about the primary keys that I mentioned? In the current
Also, when talking about whether or not the index supporting a
constraint
should be sort of 'hidden' from the user, should not we change
pg_dump to
dump unique indices using the ALTER TABLE syntax, rather than the CREATE
UNIQUE INDEX syntax? Otherwise this information will be lost.
I
Christopher Kings-Lynne wrote:
Yeah, I've got it Bruce - I still haven't had time to look into it and I
really don't know what to do about the backward compatibility issue. How do
I set up 2 identically named C functions with different parameter lists?
Oh, that is easy. When you CREATE
Christopher Kings-Lynne wrote:
Yeah, I've got it Bruce - I still haven't had time to look into it and I
really don't know what to do about the backward compatibility
issue. How do
I set up 2 identically named C functions with different parameter lists?
Oh, that is easy. When you
Christopher Kings-Lynne wrote:
Christopher Kings-Lynne wrote:
Yeah, I've got it Bruce - I still haven't had time to look into it and I
really don't know what to do about the backward compatibility
issue. How do
I set up 2 identically named C functions with different parameter lists?
Call them different C names, but name them the same in CREATE FUNCTION
funcname. Just use a different symbol name here:
CREATE [ OR REPLACE ] FUNCTION name ( [ argtype [, ...] ] )
same here
RETURNS rettype
AS
Christopher Kings-Lynne wrote:
Call them different C names, but name them the same in CREATE FUNCTION
funcname. Just use a different symbol name here:
CREATE [ OR REPLACE ] FUNCTION name ( [ argtype [, ...] ] )
same here
Scott Royston [EMAIL PROTECTED] writes:
[ various examples of comparing char and varchar ]
I see no bug here. For the CHAR datatype, trailing spaces are defined
to be insignificant. For VARCHAR and TEXT, trailing spaces are
significant. If you want to compare a CHAR value to a VARCHAR or
44 matches
Mail list logo
