mirror of https://github.com/postgres/postgres
Bruce Momjian
26 years ago
parent
196cbe4e1d
commit
99f289de49
@ -0,0 +1,56 @@ |
||||
From tgl@sss.pgh.pa.us Sun May 23 12:32:34 1999 |
||||
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) |
||||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA23977 |
||||
for <maillist@candle.pha.pa.us>; Sun, 23 May 1999 12:32:33 -0400 (EDT) |
||||
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) |
||||
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA19926; |
||||
Sun, 23 May 1999 12:32:01 -0400 (EDT) |
||||
To: Bruce Momjian <maillist@candle.pha.pa.us> |
||||
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org> |
||||
Subject: Re: [HACKERS] DEFAULT fixed |
||||
In-reply-to: Your message of Sat, 22 May 1999 21:12:19 -0400 (EDT) |
||||
<199905230112.VAA13489@candle.pha.pa.us> |
||||
Date: Sun, 23 May 1999 12:32:01 -0400 |
||||
Message-ID: <19923.927477121@sss.pgh.pa.us> |
||||
From: Tom Lane <tgl@sss.pgh.pa.us> |
||||
Status: ROr |
||||
|
||||
Bruce Momjian <maillist@candle.pha.pa.us> writes: |
||||
>> It might be best to just bite the bullet and make the parser carry |
||||
>> around both the type's OID and typmod at all times. |
||||
|
||||
> I will try to add it, but I must not that there are some cases where I |
||||
> don't have access to the atttypmod of the result, so it may not be |
||||
> possible to do it in every case. Perhaps I should just leave this for |
||||
> post 6.5, because we don't have any other bug reports on it. |
||||
|
||||
After further thought, I think this may be a more difficult and subtle |
||||
issue than we've realized. In the current state of the system, there |
||||
are many places where you have a value that you can only know the type |
||||
OID for, not atttypmod --- specifically, any intermediate expression |
||||
result. Barring reworking the entire function-call mechanism to pass |
||||
atttypmod around, that's not going to be possible to change. |
||||
|
||||
The only context where you really know atttypmod is where you have |
||||
just fetched a value out of a table column or are about to store a |
||||
value into a table column. When storing, you need to be prepared to |
||||
coerce the given value to the right type if *either* type OID or |
||||
atttypmod is different --- but, in general, you don't know atttypmod |
||||
for the given value. (In the cases I know of, you can deduce it by |
||||
examining the value itself, but this requires type-specific knowledge.) |
||||
|
||||
So on the whole I think this is something that has to be dealt with |
||||
at the point of storing data into a tuple. Maybe we need a new |
||||
fundamental operation for types that pay attention to atttypmod: |
||||
"make this value match the typmod of the target column, which is |
||||
thus-and-so". Trying to attack the problem from the source side by |
||||
propagating typmod all around the parser is probably doomed to failure, |
||||
because there will be many contexts where there's no way to know it. |
||||
|
||||
Since you have a fix for the only symptom reported to date, I'm |
||||
inclined to agree that we should leave well enough alone for now; |
||||
there are other, bigger, problems that we need to address for 6.5. |
||||
But I think we'll have to come back to this issue later. |
||||
|
||||
regards, tom lane |
||||
|
||||
@ -0,0 +1,59 @@ |
||||
From tgl@sss.pgh.pa.us Sun May 23 18:59:22 1999 |
||||
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) |
||||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA08491 |
||||
for <maillist@candle.pha.pa.us>; Sun, 23 May 1999 18:59:21 -0400 (EDT) |
||||
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) |
||||
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA27952; |
||||
Sun, 23 May 1999 18:58:53 -0400 (EDT) |
||||
To: Bruce Momjian <maillist@candle.pha.pa.us> |
||||
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org> |
||||
Subject: Re: [HACKERS] DEFAULT fixed |
||||
In-reply-to: Your message of Sat, 22 May 1999 21:12:19 -0400 (EDT) |
||||
<199905230112.VAA13489@candle.pha.pa.us> |
||||
Date: Sun, 23 May 1999 18:58:52 -0400 |
||||
Message-ID: <27950.927500332@sss.pgh.pa.us> |
||||
From: Tom Lane <tgl@sss.pgh.pa.us> |
||||
Status: ROr |
||||
|
||||
Actually, it's not as fixed as all that... |
||||
|
||||
create table foo1 (a char(5) default '', b int4); |
||||
insert into foo1 (b) values (334); |
||||
select * from foo1; |
||||
a | b |
||||
-----+--- |
||||
|334 |
||||
(1 row) |
||||
|
||||
Good, the basic case is fixed, but: |
||||
|
||||
create table foo2 (a char(5) default text '', b int4); |
||||
insert into foo2 (b) values (334); |
||||
select * from foo2; |
||||
a| b |
||||
-+-- |
||||
|16 |
||||
(1 row) |
||||
|
||||
Ooops. |
||||
|
||||
What you seem to have done is twiddle the handling of DEFAULT clauses |
||||
so that the value stored for the default expression is pre-coerced to the |
||||
column type. That's good as far as it goes, but it fails in cases where |
||||
the stored value has to be of a different type. |
||||
|
||||
My guess is that what *really* ought to happen here is that |
||||
transformInsertStmt should check the type of the value it's gotten from |
||||
the default clause and apply coerce_type if necessary. |
||||
|
||||
Unless someone can come up with a less artificial example than the one |
||||
above, I'm inclined to leave it alone for 6.5. This is the same code |
||||
area that will have to be redone to fix the INSERT ... SELECT problem |
||||
I was chasing earlier today: coercion of the values produced by SELECT |
||||
will have to wait until the tail end of transformInsertStmt, and we |
||||
might as well make wrong-type default constants get fixed in the same |
||||
place. So I'm not eager to write some throwaway code to patch a problem |
||||
that no one is likely to see in practice. What's your feeling about it? |
||||
|
||||
regards, tom lane |
||||
|
||||
@ -0,0 +1,97 @@ |
||||
From tgl@sss.pgh.pa.us Mon Jun 14 20:50:41 1999 |
||||
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) |
||||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id UAA19110 |
||||
for <maillist@candle.pha.pa.us>; Mon, 14 Jun 1999 20:50:39 -0400 (EDT) |
||||
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) |
||||
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id UAA21506; |
||||
Mon, 14 Jun 1999 20:51:07 -0400 (EDT) |
||||
To: Bruce Momjian <maillist@candle.pha.pa.us> |
||||
cc: Roman.Hodek@informatik.uni-erlangen.de, olly@lfix.co.uk, |
||||
PostgreSQL-development <pgsql-hackers@postgreSQL.org> |
||||
Subject: Cleaning up function interface (was Re: Patch for m68k architecture) |
||||
In-reply-to: Your message of Mon, 14 Jun 1999 17:53:25 -0400 (EDT) |
||||
<199906142153.RAA16276@candle.pha.pa.us> |
||||
Date: Mon, 14 Jun 1999 20:51:06 -0400 |
||||
Message-ID: <21504.929407866@sss.pgh.pa.us> |
||||
From: Tom Lane <tgl@sss.pgh.pa.us> |
||||
Status: RO |
||||
|
||||
Bruce Momjian <maillist@candle.pha.pa.us> writes: |
||||
>> ANSI C says results are undefined if you call a function via pointer |
||||
>> and the pointer is declared to return another type than the function |
||||
>> actually returns. So m68k compilers conform to the standard here. |
||||
|
||||
> Yes, we admit that we break the standard with fmgr_ptr, because we |
||||
> return a variety of values depending on what function they call. It |
||||
> appears the egcs optimization on the powerpc or alpha cause a problem |
||||
> when optimization is -O2, but not -O. We may see more platforms with |
||||
> problems as optimizers get smarter. |
||||
|
||||
Seeing as how we also know that the function-call interface ought to be |
||||
redesigned to handle NULLs better, maybe we should just bite the bullet |
||||
and fix all of these problems at once by adopting a new standard |
||||
interface for everything that can be called via fmgr. It'd uglify the |
||||
code, no doubt, but I think we are starting to see an accumulation of |
||||
problems that justify doing something. |
||||
|
||||
Here is a straw-man proposal: |
||||
|
||||
Datum function (bool *resultnull, |
||||
Datum *args, |
||||
bool *argnull, |
||||
int nargs) |
||||
|
||||
args[i] is the i'th parameter, or undefined (perhaps always 0?) |
||||
when argnull[i] is true. The function is responsible for setting |
||||
*resultnull, and returns a Datum value if *resultnull is false. |
||||
Most standard functions could ignore nargs since they'd know what it |
||||
should be, but we ought to pass it for flexibility. |
||||
|
||||
A useful addition to this scheme would be for fmgr to preset *resultnull |
||||
to the OR of the input argnull[] array just before calling the function. |
||||
In the typical case where the function is "strict" (ie, result is NULL |
||||
if any input is NULL), this would save the function from having to look |
||||
at argnull[] at all; it'd just check *resultnull and immediately return |
||||
if true. |
||||
|
||||
As an example, int4 addition goes from |
||||
|
||||
int32 |
||||
int4pl(int32 arg1, int32 arg2) |
||||
{ |
||||
return arg1 + arg2; |
||||
} |
||||
|
||||
to |
||||
|
||||
Datum |
||||
int4pl (bool *resultnull, Datum *args, bool *argnull, int nargs) |
||||
{ |
||||
if (*resultnull) |
||||
return (Datum) 0; /* value doesn't really matter ... */ |
||||
/* we can ignore argnull and nargs */ |
||||
|
||||
return Int32GetDatum(DatumGetInt32(args[0]) + DatumGetInt32(args[1])); |
||||
} |
||||
|
||||
This is, of course, much uglier than the existing code, but we might be |
||||
able to improve matters with some well-chosen macros for the boilerplate |
||||
parts. What we actually end up writing might look something like |
||||
|
||||
Datum |
||||
int4pl (PG_FUNCTION_ARGS) |
||||
{ |
||||
PG_STRICT_FUNCTION( /* encapsulates null check */ |
||||
PG_ARG0_INT32; |
||||
PG_ARG1_INT32; |
||||
|
||||
PG_RESULT_INT32( arg0 + arg1 ); |
||||
); |
||||
} |
||||
|
||||
where the macros expand to things like "int32 arg0 = DatumGetInt32(args[0])" |
||||
and "return Int32GetDatum( x )". It'd be worth a little thought to |
||||
try to set up a group of macros like that, I think. |
||||
|
||||
regards, tom lane |
||||
|
||||
@ -0,0 +1,66 @@ |
||||
From owner-pgsql-hackers@hub.org Tue Jun 1 22:31:18 1999 |
||||
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4]) |
||||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA09988 |
||||
for <maillist@candle.pha.pa.us>; Tue, 1 Jun 1999 22:31:17 -0400 (EDT) |
||||
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id WAA18944 for <maillist@candle.pha.pa.us>; Tue, 1 Jun 1999 22:08:09 -0400 (EDT) |
||||
Received: from hub.org (hub.org [209.167.229.1]) |
||||
by hub.org (8.9.3/8.9.3) with ESMTP id WAA75604; |
||||
Tue, 1 Jun 1999 22:01:31 -0400 (EDT) |
||||
(envelope-from owner-pgsql-hackers@hub.org) |
||||
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 01 Jun 1999 22:01:11 +0000 (EDT) |
||||
Received: (from majordom@localhost) |
||||
by hub.org (8.9.3/8.9.3) id WAA75519 |
||||
for pgsql-hackers-outgoing; Tue, 1 Jun 1999 22:01:09 -0400 (EDT) |
||||
(envelope-from owner-pgsql-hackers@postgreSQL.org) |
||||
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-hackers@postgreSQL.org using -f |
||||
Received: from localhost.localdomain (h246.ozemail2.ozemail.com.au [203.108.14.246]) |
||||
by hub.org (8.9.3/8.9.3) with ESMTP id WAA75452 |
||||
for <pgsql-hackers@hub.org>; Tue, 1 Jun 1999 22:00:50 -0400 (EDT) |
||||
(envelope-from chris.bitmead@bigfoot.com) |
||||
Received: from bigfoot.com (localhost [127.0.0.1]) |
||||
by localhost.localdomain (8.8.7/8.8.7) with ESMTP id KAA04059 |
||||
for <pgsql-hackers@hub.org>; Wed, 2 Jun 1999 10:50:11 +1000 |
||||
Message-ID: <37547FC3.40106A5E@bigfoot.com> |
||||
Date: Wed, 02 Jun 1999 10:50:11 +1000 |
||||
From: Chris Bitmead <chris.bitmead@bigfoot.com> |
||||
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.6 i686) |
||||
X-Accept-Language: en |
||||
MIME-Version: 1.0 |
||||
To: pgsql-hackers@hub.org |
||||
Subject: Re: [HACKERS] ALTER TABLE ADD COLUMN |
||||
References: <199906011436.KAA23479@candle.pha.pa.us> |
||||
Content-Type: text/plain; charset=us-ascii |
||||
Content-Transfer-Encoding: 7bit |
||||
Sender: owner-pgsql-hackers@postgreSQL.org |
||||
Precedence: bulk |
||||
Status: RO |
||||
|
||||
Bruce Momjian wrote: |
||||
|
||||
> Our TODO now has: |
||||
> |
||||
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place |
||||
> |
||||
> I don't think any of us understand the issues on this one. |
||||
|
||||
Let me guess at the problem. When you add a column, it doesn't change |
||||
all the records, therefore the column must be added at the end. This |
||||
means that the columns will not be in the same order as if you had |
||||
created them from scratch. |
||||
|
||||
There seem to be three solutions: |
||||
a) Go to a much more sophisticated schema system, with versions and |
||||
version numbers (fairly hard but desirable to fix other schema change |
||||
problems). Then insert the column in the position it is supposed to be |
||||
in. |
||||
|
||||
b) Fix the copy command to input and output the columns, not in the |
||||
order they are in, but in the order they would be in on re-creation. |
||||
|
||||
c) make the copy command take arguments specifying the field names, like |
||||
INSERT can do. |
||||
|
||||
I think it would be good if Postgres had all 3 features. Probably (b) is |
||||
the least work. |
||||
|
||||
|
||||
@ -0,0 +1,49 @@ |
||||
From zalman@netcom.com Tue Mar 16 18:01:18 1999 |
||||
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4]) |
||||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA24313 |
||||
for <maillist@candle.pha.pa.us>; Tue, 16 Mar 1999 18:01:17 -0500 (EST) |
||||
Received: from netcom15.netcom.com (zalman@netcom15.netcom.com [192.100.81.128]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id RAA15235 for <maillist@candle.pha.pa.us>; Tue, 16 Mar 1999 17:56:56 -0500 (EST) |
||||
Received: (from zalman@localhost) |
||||
by netcom15.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id OAA28174; |
||||
Tue, 16 Mar 1999 14:55:33 -0800 (PST) |
||||
From: Zalman Stern <zalman@netcom.com> |
||||
Message-Id: <199903162255.OAA28174@netcom15.netcom.com> |
||||
Subject: Re: [SQL] How match percent sign in SELECT using LIKE? |
||||
To: maillist@candle.pha.pa.us (Bruce Momjian) |
||||
Date: Tue, 16 Mar 1999 14:55:33 -0800 (PST) |
||||
Cc: zalman@netcom.com, herouth@oumail.openu.ac.il, pgsql-sql@postgreSQL.org |
||||
In-Reply-To: <199903162226.RAA20904@candle.pha.pa.us> from "Bruce Momjian" at Mar 16, 99 05:26:09 pm |
||||
X-Mailer: ELM [version 2.4 PL25] |
||||
MIME-Version: 1.0 |
||||
Content-Type: text/plain; charset=US-ASCII |
||||
Content-Transfer-Encoding: 7bit |
||||
Status: ROr |
||||
|
||||
Bruce Momjian wrote: |
||||
> That is also an excellent idea. Just convert their escape to \ inside |
||||
> the parser. Of course, they still have to use \\ to get a \, as in any |
||||
> string. Great idea. |
||||
|
||||
You can even make it fully compliant if you want. (There are of course |
||||
backward compatibility problems. I'm not sure what the Postgres policy is |
||||
on this.) |
||||
|
||||
- If the escape character is backslash, do nothing. |
||||
- Otherwise, turn all backslashes in the string to double backslashes. |
||||
- If the escape character is not set, stop here. |
||||
- Turn all occurences of the escape character into a backslash except |
||||
where the escape character is doubled, where it should be made into a |
||||
single occurence. |
||||
(Optionally, if "\n" is just an 'n' character, you can handle double |
||||
occurences of the escape character by turning the first one into a |
||||
backslash.) |
||||
|
||||
Probably the best bet for PostgreSQL programmers is to always code Like |
||||
clauses with an ESCAPE '\' (or however its written). |
||||
|
||||
I really wish they'd chosen a character other than underscore for the |
||||
"match one" wildcard... Is there any standard practice for seperating words |
||||
in table names? |
||||
|
||||
-Z- |
||||
|
||||
Loading…
Reference in new issue