pgsql-server/ oc/src/sgml/catalogs.sgml rc/bac ...
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@svr1.postgresql.org 04/01/06 19:55:19
Modified files:
doc/src/sgml : catalogs.sgml
src/backend/bootstrap: bootstrap.c
src/backend/catalog: pg_aggregate.c pg_proc.c
src/backend/commands: functioncmds.c
src/backend/nodes: copyfuncs.c equalfuncs.c
src/backend/parser: gram.y
src/backend/utils/adt: sets.c
src/backend/utils/fmgr: fmgr.c
src/include/catalog: catversion.h pg_attribute.h pg_class.h
pg_proc.h
src/include/nodes: nodes.h parsenodes.h
src/pl/plperl : plperl.c
src/pl/plpgsql/src: pl_comp.c
src/pl/plpython: plpython.c
src/pl/tcl : pltcl.c
Log message:
Apply the core parts of Dennis Bjorklund's patch to allow function
parameters to be declared with names. pg_proc has a column to store
names, and CREATE FUNCTION can insert data into it, but that's all as
yet. I need to do more work on the pg_dump and plpgsql portions of the
patch before committing those, but I thought I'd get the bulky changes
in before the tree drifts under me.
initdb forced due to pg_proc change.
Does this complete this TODO?
o Allow parameters to be specified by name and type during
definition
---------------------------------------------------------------------------
Tom Lane wrote:
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@svr1.postgresql.org 04/01/06 19:55:19Modified files:
doc/src/sgml : catalogs.sgml
src/backend/bootstrap: bootstrap.c
src/backend/catalog: pg_aggregate.c pg_proc.c
src/backend/commands: functioncmds.c
src/backend/nodes: copyfuncs.c equalfuncs.c
src/backend/parser: gram.y
src/backend/utils/adt: sets.c
src/backend/utils/fmgr: fmgr.c
src/include/catalog: catversion.h pg_attribute.h pg_class.h
pg_proc.h
src/include/nodes: nodes.h parsenodes.h
src/pl/plperl : plperl.c
src/pl/plpgsql/src: pl_comp.c
src/pl/plpython: plpython.c
src/pl/tcl : pltcl.cLog message:
Apply the core parts of Dennis Bjorklund's patch to allow function
parameters to be declared with names. pg_proc has a column to store
names, and CREATE FUNCTION can insert data into it, but that's all as
yet. I need to do more work on the pg_dump and plpgsql portions of the
patch before committing those, but I thought I'd get the bulky changes
in before the tree drifts under me.
initdb forced due to pg_proc change.---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Does this complete this TODO?
o Allow parameters to be specified by name and type during
definition
Uh, no; the lack of documentation updates being one of the more glaring
omissions. I should think that psql's \df needs some thought too, as
well as the other PL languages besides plpgsql. What we've got here is
just the core infrastructure for a feature, not the full feature.
regards, tom lane
On Tue, 6 Jan 2004, Tom Lane wrote:
Does this complete this TODO?
o Allow parameters to be specified by name and type during
definitionUh, no; the lack of documentation updates being one of the more glaring
omissions. I should think that psql's \df needs some thought too, as
well as the other PL languages besides plpgsql. What we've got here is
just the core infrastructure for a feature, not the full feature.
Yes, my patch only handles pl/pgsql so far. The patch was big enough as it
was. I've not looked at it since I sent it in, I wanted to see what
happend with it before spending more time on it.
Things to do in the future is
1) Documentation. I pointed that out when I sent the patch I think.
I didn't do this partly because I had some problem building the docs
and partly because I'm not sure how to write it. It must of course be
done before a release.
2) Making it work for pl/sql. This involves changing the main parser
and maybe how the whole system for parameters work. In pg today the
expression parser supports variables of the form $<nat>. My plan
was to change this to $<ident> or whatever it becomes now when the
variables are not an ident anymore (not a problem).
This update can however change a lot if one want to do it correctly,
and support $<ident> variables in all places where we today support
$<nat>. For example to let the pl-languages supply values for named
arguments.
About the ident problem and the parser, I also got these shift/reduce
problems and just took the easy way out of using ident. It was not
wrong to use ident. it just was not optimal in that it rules out some
names that are now possible to use. It didn't worry me as much as it
seemed to worry Tom.
3) Other languages. I don't think I can/want update all of them. I feel
it's enough to put the core in and the language maintainers can make
use of this feature if it fits their language.
4) There are more places where one might want to extend it. For example
to handle the names for NEW/OLD in triggers. These names can now be
user defined. Not a big change, but it's possible now.
5) Probably something more that I've forgotten now.
I'm happy that the work is accepted. I spend a lot of time especially on
the catalog parts. That is a very fragile part of pg and it's not fun to
make changes there. There are assumptions in the code that is not clear to
a new coder.
ps I've just changed my email name to my real name which is Dennis
Bj�rklund. I did that 5 years ago (still using pine) and got angry mails
back saying that my mails where broken. I hope the todays email programs
can handle non-ascii names better...
--
/Dennis Bj�rklund
On Wed, Jan 07, 2004 at 06:58:37 +0100,
Dennis Bj�rklund <db@zigo.dhs.org> wrote:
ps I've just changed my email name to my real name which is Dennis
Bj�rklund. I did that 5 years ago (still using pine) and got angry mails
back saying that my mails where broken. I hope the todays email programs
can handle non-ascii names better...
It still isn't legal to use non US ASCII characters in headers. There
is an encoding scheme that can be used for the subject header. There
isn't such a system for the from header. While most mail programs
won't crash when encoutering non ASCII, not everyone is going to see
your name properly. People who are using Latin1 for display will probably
see things correctly, but people using other extensions of US ASCII
might see such things as graphics sysmbols rather than an o with an
umlat.
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Does this complete this TODO?
o Allow parameters to be specified by name and type during
definitionUh, no; the lack of documentation updates being one of the more glaring
omissions. I should think that psql's \df needs some thought too, as
well as the other PL languages besides plpgsql. What we've got here is
just the core infrastructure for a feature, not the full feature.
Thanks. TODO updated as "not done".
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruno Wolff III wrote:
On Wed, Jan 07, 2004 at 06:58:37 +0100,
Dennis Bj?rklund <db@zigo.dhs.org> wrote:ps I've just changed my email name to my real name which is Dennis
Bj?rklund. I did that 5 years ago (still using pine) and got angry mails
back saying that my mails where broken. I hope the todays email programs
can handle non-ascii names better...It still isn't legal to use non US ASCII characters in headers. There
is an encoding scheme that can be used for the subject header. There
isn't such a system for the from header. While most mail programs
won't crash when encoutering non ASCII, not everyone is going to see
your name properly. People who are using Latin1 for display will probably
see things correctly, but people using other extensions of US ASCII
might see such things as graphics sysmbols rather than an o with an
umlat.
I see a question mark with elm-ME, but that is OK.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Wed, 7 Jan 2004, Bruno Wolff III wrote:
ps I've just changed my email name to my real name which is Dennis
Bj�rklund.It still isn't legal to use non US ASCII characters in headers. There
is an encoding scheme that can be used for the subject header.
I hoped that pine was going to do it the correct way nowadays. I guess I
have to remove it again (or read up on the subject so I know what is
correct and what is not). I don't mind people not being able to read it,
but I don't want to send non standard emails.
--
/Dennis Bj�rklund
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db@zigo.dhs.org> writes:
On Wed, 7 Jan 2004, Bruno Wolff III wrote:
ps I've just changed my email name to my real name which is Dennis
Bj�rklund.It still isn't legal to use non US ASCII characters in headers. There
is an encoding scheme that can be used for the subject header.
I hoped that pine was going to do it the correct way nowadays. I guess I
have to remove it again (or read up on the subject so I know what is
correct and what is not). I don't mind people not being able to read it,
but I don't want to send non standard emails.
AFAICS, you're sending
From: =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db@zigo.dhs.org>
which is an instance of the encoding scheme Bruno mentioned. I have
never heard that it is only supposed to be used in Subject:
... certainly there are a ton of people besides you who use it in From:.
So I think you are legal.
Whether your name is being displayed nicely is a whole 'nother matter.
On my machine I see "Dennis Bj-rklund" or "Dennis Bj rklund" depending
on which display I look at :-(. I think this is a font issue, but I
don't have enough motivation to track it down...
regards, tom lane
On Wed, Jan 07, 2004 at 15:17:26 -0500,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
AFAICS, you're sending
From: =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db@zigo.dhs.org>
which is an instance of the encoding scheme Bruno mentioned. I have
never heard that it is only supposed to be used in Subject:
... certainly there are a ton of people besides you who use it in From:.
So I think you are legal.
Yep. I thought he was using the Latin1 code for this. I double checked
the characters used in this escape sequence and they are valid to use
in an ATOM as defined by rfc 2822. So the message is legal for purposes
of email. That rfc is silent about whether the escape string should
be displayed by the client. I am not sure which one would cover that,
but apparently clients do understand it in more than just the subject
header. Older clients that don't understand that escape string will show
the above string.
Whether your name is being displayed nicely is a whole 'nother matter.
On my machine I see "Dennis Bj-rklund" or "Dennis Bj rklund" depending
on which display I look at :-(. I think this is a font issue, but I
don't have enough motivation to track it down...
Maybe on your screen it displays as whatever character F6 is in the character
set used by your display or it may be that your font doesn't isn't a Latin1
font.
AFAICS, you're sending
From: =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db@zigo.dhs.org>
which is an instance of the encoding scheme Bruno mentioned. I have
never heard that it is only supposed to be used in Subject:
... certainly there are a ton of people besides you who use it in From:.
So I think you are legal.Whether your name is being displayed nicely is a whole 'nother matter.
On my machine I see "Dennis Bj-rklund" or "Dennis Bj rklund" depending
on which display I look at :-(. I think this is a font issue, but I
don't have enough motivation to track it down...
It displays perfectly in Windows :)
Chris
On Thu, Jan 08, 2004 at 09:20:02AM +0800, Christopher Kings-Lynne wrote:
Whether your name is being displayed nicely is a whole 'nother matter.
On my machine I see "Dennis Bj-rklund" or "Dennis Bj rklund" depending
on which display I look at :-(. I think this is a font issue, but I
don't have enough motivation to track it down...It displays perfectly in Windows :)
I see it OK on Mandrake Linux too, FWIW.
rxvt -fn -*-fixed-medium-r-normal-*-*-140-75-75-*-*-iso8859-15
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La grandeza es una experiencia transitoria. Nunca es consistente.
Depende en gran parte de la imaginaci�n humana creadora de mitos"
(Irulan)