CREATE LANGUAGE
Is there a reason why it's CREATE LANGUAGE 'string' and not CREATE
LANGUAGE "ident"? I'd like to allow both to make it consistent with the
other create commands. SQL also uses identifier syntax for language
names.
Also, what is LANCOMPILER for? If it's just a comment we ought to use
pg_description.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a reason why it's CREATE LANGUAGE 'string' and not CREATE
LANGUAGE "ident"? I'd like to allow both to make it consistent with the
other create commands. SQL also uses identifier syntax for language
names.
Seems reasonable to me. Don't overlook the CREATE FUNCTION ... LANGUAGE
clause, too.
Also, what is LANCOMPILER for? If it's just a comment we ought to use
pg_description.
I think the original idea might have been to someday support
auto-building of compiled functions. (Though a setup allowing one to
invoke make with suitable arguments would probably be far more useful
than a bare compiler name.) I'm not in a hurry to rip it out until we
have designed such a facility, anyway. There are a lot of vestigial
features in Postgres that we might someday resurrect/implement. I tend
to view those things as TODO markers, not stuff to rip out to save a
byte or two.
regards, tom lane
Tom Lane writes:
Also, what is LANCOMPILER for? If it's just a comment we ought to use
pg_description.I think the original idea might have been to someday support
auto-building of compiled functions.
That's what I though, too. My concern is mostly that this clause should
be optional, because right now it needs to be filled with in with useless
stuff.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
That's what I though, too. My concern is mostly that this clause should
be optional,
Oh. No objection to that --- just drop an empty string into the
pg_language column if it's omitted.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
That's what I though, too. My concern is mostly that this clause should
be optional,Oh. No objection to that --- just drop an empty string into the
pg_language column if it's omitted.
Also, should we remove documentation about the field. Confusing to
document something that is meaningless.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Perhaps change the documentation instead so it reflects this is a
deprecated feature that one day may be resurrected?
IMHO, totally removing reference to it in the documentation will confuse
people who have come across it before and wondered where it went.
+ Justin
Bruce Momjian wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
That's what I though, too. My concern is mostly that this clause should
be optional,Oh. No objection to that --- just drop an empty string into the
pg_language column if it's omitted.Also, should we remove documentation about the field. Confusing to
document something that is meaningless.-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026---------------------------(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
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi