On Fri, 2002-07-12 at 08:50, Tom Lane wrote:
> 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
> significan
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 T
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
> >
> 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:
> > 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 para
> 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
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 FU
> > 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
> "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 th
"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
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
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
> 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 need
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 P
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 key..
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 ca
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 al
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 ('S
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
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:
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 re
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 boobytr
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 broadcast
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?
http://archives.po
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 dif
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
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 t
Groff, Dana wrote:
> I think that we are getting into two or three issues here. If I may:
>
> (1) Is DROP TABLE acceptable by the standard?
> (2) Should we break "old" functionality?
> (3) assuming we support the old syntax:
> should DROP TABLE be functionally
I can't improve performance on this
query:
SELECT supplier.name, supplier.addressFROM supplier, nationWHERE supplier.suppkey
IN( SELECT partsupp.suppkey FROM partsupp WHERE partsupp.partkey
IN(SELECT part.partkeyFROM partWHERE part.name
like 'forest%' )
> 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 se
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 b
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
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: Y
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 m
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 =
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 interv
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
Function
Destroy a table.
Format
:
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 B
> > 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
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
> >
> > 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:26:01PM +0900, Tatsuo Ishii wrote:
> > 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 n
> > > > 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
> >
> 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(encodin
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 defi
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 com
46 matches
Mail list logo
