Richard Hall wrote:
But if THIS solution is implemented then
QUOTE('MyEndMarker')
and
MyEndMarker
become noise words and it seems the parser could just assume to handle everything
between
CREATE FUNCTION ... AS
and
LANGUAGE
as the delimiters for a function definition.
But as that's
Richard Hall [EMAIL PROTECTED] writes:
But if THIS solution is implemented then
QUOTE('MyEndMarker')
and
MyEndMarker
become noise words and it seems the parser could just assume to handle
everything between
CREATE FUNCTION ... AS
and
LANGUAGE
as the delimiters for a
On Mon, 15 Sep 2003, Tom Lane wrote:
Hm, dollar quoting doesn't sound too bad. I could go with that,
unless someone has a better idea?
I don't mind dollar quoting. How about block quoting? That describes
what it's used for, rather than what it looks like.
Jon
On Sat, 13 Sep 2003, Miko O'Sullivan wrote:
[EMAIL PROTECTED] (Jon Jensen) wrote in message news:[EMAIL PROTECTED]...
INSERT INTO sometable (5, \.
a
very long
string
\.
);
I'm delighted to hear that here docs are being discussed for postgres.
In the world of Perl here docs
sendmail.cf
Sean Chittenden wrote:
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents.
Couldn't we allow at the beginning of the line to mean 'here' document?
No; you could easily be breaking existing queries, for example
Let me jump in for half a second here
Can we add digits to the allowed character set of the marker? It'd make
life easier for languages that check if the quoting marker actually
occurs in the text to be quoted.
Jan
Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Using $$[.*]\n as a lexical token is a quasi-problematic
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I think calling it 'here-document' quoting is possibly unwise - it is
sufficiently different from here documents in shell and perl contexts to
make it confusing.
I agree. I've tried to think of a better alternative name, but without
much
quote-less quoting
:-)
Robert Treat
On Mon, 2003-09-15 at 02:38, Andrew Dunstan wrote:
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Hannu Krosing [EMAIL PROTECTED] writes:
Tom Lane kirjutas P, 14.09.2003 kell 18:58:
Those seem pretty unmemorable and
Jon Jensen wrote:
On Sat, 13 Sep 2003, Miko O'Sullivan wrote:
[EMAIL PROTECTED] (Jon Jensen) wrote in message news:[EMAIL PROTECTED]...
INSERT INTO sometable (5, \.
a
very long
string
\.
);
I'm delighted to hear that here docs are being discussed for postgres.
In the world of Perl
Jon Jensen [EMAIL PROTECTED] writes:
On Sat, 13 Sep 2003, Miko O'Sullivan wrote:
In Perl, the rule for here docs is NOT it starts immediately after
the definition of the terminator (as in your example). The rule is
it starts on the first line after the end of the command in which the
On Mon, 15 Sep 2003, Tom Lane wrote:
In Perl, the rule for here docs is NOT it starts immediately after
the definition of the terminator (as in your example). The rule is
it starts on the first line after the end of the command in which the
terminator appears. There's a very good reason
Jan Wieck [EMAIL PROTECTED] writes:
Can we add digits to the allowed character set of the marker?
We can't allow a digit right after the opening dollar sign; that would
look like a parameter.
I suppose we could allow $identifier$ though. That might be the easiest
compromise.
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Can we add digits to the allowed character set of the marker?
We can't allow a digit right after the opening dollar sign; that would
look like a parameter.
I suppose we could allow $identifier$ though. That might be the easiest
I think calling it 'here-document' quoting is possibly unwise - it is
sufficiently different from here documents in shell and perl contexts to
make it confusing.
I agree. I've tried to think of a better alternative name, but without
much success.
We could call it meta-quoting, or
14, 2003 1:49 AM
Subject: Re: [HACKERS] massive quotes?
Attached is a proof-of-concept diff that makes the main SQL parser
accept quoted strings in the style recently discussed ($Q$ ... $Q$).
To complete the feature, we'd need to make the plpgsql parser do the
same, update psql to understand
[EMAIL PROTECTED] (Jon Jensen) wrote in message news:[EMAIL PROTECTED]...
INSERT INTO sometable (5, \.
a
very long
string
\.
);
I'm delighted to hear that here docs are being discussed for postgres.
In the world of Perl here docs make life SO MUCH easier by allowing
for independent
Hannu Krosing [EMAIL PROTECTED] writes:
Tom Lane kirjutas P, 14.09.2003 kell 18:58:
Those seem pretty unmemorable and content-free, though. Any other ideas
out there?
Considering that we use $$ instead of quotes we could call it dollarring
instead of quoting ;)
...
double-dollar quoting
Attached is a proof-of-concept diff that makes the main SQL parser
accept quoted strings in the style recently discussed ($Q$ ... $Q$).
To complete the feature, we'd need to make the plpgsql parser do the
same, update psql to understand this, update pg_dump to use this style
of quoting for
Let me jump in for half a second here (no pun intended), but what
about the use of back quotes? ` `? Use a very limited escaping
policy of \` = ` and \\ = \ .
Actually, having to double backslashes is one of the things I want
to get rid of. The here-document-based ideas seem to allow
Sean Chittenden [EMAIL PROTECTED] writes:
Using $$[.*]\n as a lexical token is a quasi-problematic as the anchor
is the newline, something that SQL has been free of for as long as I'm
aware of. By using a static lexical token, such as @@, newline's
aren't important, thus reducing the number
Tom Lane wrote:
Note that there is no particular need to insist on any nearby newlines.
If the construct is written just following an identifier or keyword,
then you do need some intervening whitespace to keep the $Q$ from being
read as part of that identifier, but I doubt this will bother
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Note that there is no particular need to insist on any nearby newlines.
If the construct is written just following an identifier or keyword,
then you do need some intervening whitespace to keep the $Q$ from being
read as part of that
Sean Chittenden [EMAIL PROTECTED] writes:
... then @autoconf me harder@ could be used as the start and ending
token,
Hm, I should have read your message more carefully --- I missed the bit
at the middle where you propose nearly the same idea I had ;-). But the
flex patterns you wrote don't
Tom Lane wrote:
After sleeping on it, I do think that tying the mechanism to newlines
is just unnecessary complication. I'm currently leaning to an idea that
was suggested yesterday by (I think) Andreas: let the quote start marker
be a token of the form
dollarsign zero-or-more-letters
Andrew Dunstan [EMAIL PROTECTED] writes:
I'd like to see pg_dump use this mechanism for quoting, at least for
function bodies. I guess it could retrieve the text and then keep
generating delimiters until it found one that didn't occur inside the
text.
Right, that was what I had in mind.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'd like to see pg_dump use this mechanism for quoting, at least for
function bodies. I guess it could retrieve the text and then keep
generating delimiters until it found one that didn't occur inside the
text.
Right, that was
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'd like to see pg_dump use this mechanism for quoting, at least for
function bodies. I guess it could retrieve the text and then keep
generating delimiters until it found one that didn't occur inside the
text.
Right, that was
... then @autoconf me harder@ could be used as the start and
ending token,
Hm, I should have read your message more carefully --- I missed the
bit at the middle where you propose nearly the same idea I had ;-).
But the flex patterns you wrote don't actually support this do they?
They
Tilo Schwarz wrote:
What about the Python approach: The literal text is enclosed either in a pair
of three single quotes or three double quotes. So you can do (e.g. in the
python shell)
It'll only make plpyhon functions harder to write, if you need to use
longstring quoting INSIDE your plpython
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight, it seems. That
\beginliteral stuff is psql
How is that relevant? It's still parseable with parameter placeholders in
place of literal parameters.
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Presumably \beginliteral \endliteral would be psql's way of specifying
parameters to ship over as
Andrew Dunstan wrote:
Tom Lane wrote:
Some people think a sql syntax solution is needed, and some do not.
So does this get resolved by a vote?
A non-sql-syntax solution is useless.
Regards,
Andreas
---(end of broadcast)---
TIP 1: subscribe
On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Again: not psql, but sql language itself must provide this.
No out-of-band, because this would require splitting the script in pieces.
What's
Richard Huxton wrote:
On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Again: not psql, but sql language itself must provide this.
No out-of-band, because this would require splitting the script in
On Thu, 10 Sep 2003, Doug McNaught wrote:
But Perl/DBI does escaping for you, so all you'd have to do is:
$sth = $dbh-prepare
(CREATE FUNCTION foo(x text) RETURNS text AS ? LANGUAGE 'plpgsql');
$sth-execute($function_body);
where $function_body is the unescaped form of the function.
On Thursday 11 September 2003 10:40, Andreas Pflug wrote:
Richard Huxton wrote:
On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Again: not psql, but sql language itself must provide this.
No
Jon Jensen [EMAIL PROTECTED] writes:
On Thu, 10 Sep 2003, Doug McNaught wrote:
But Perl/DBI does escaping for you, so all you'd have to do is:
Only because the FE protocol is new and the DBD driver hasn't switched to
using it.
$sth = $dbh-prepare
(CREATE FUNCTION foo(x text) RETURNS
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Some people think a sql syntax solution is needed, and some do not.
So does this get resolved by a vote?
A vote is a little premature when we don't have fully-developed
alternatives to choose from. The psql
Bruce Momjian wrote:
Tom Lane wrote:
The discussion so far today seems to be entirely a rehash of arguments
already made (and in many cases already rebutted). Rather than wasting
list bandwidth with this, I think each camp ought to go off and do their
homework. Give us *details* of how your
Bruce Momjian [EMAIL PROTECTED] writes:
Another idea would be to enable another set of quoting characters, like:
Yeah, I was toying with that also; it would be nearly the same as the
psql literal proposal, but pushed into the backend. I am not sure what
the quoting symbols should look like
Andreas Pflug wrote:
Bruce Momjian wrote:
Tom Lane wrote:
The discussion so far today seems to be entirely a rehash of arguments
already made (and in many cases already rebutted). Rather than wasting
list bandwidth with this, I think each camp ought to go off and do their
homework.
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess. I might be wrong
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess. I
Andreas Pflug wrote:
Bruce Momjian wrote:
You mean if the special quotes are -- and --, - would be the
same as '-'?
If they work as the standard ' quote (and that seems to be Toms
intention), obviously.
Besides, we have to care specially about --. Remember the complaints
Sergio A. Kessler wrote:
Too sad, all special chars are used up for operators
also '{' '}' are used ?
I've only seen this in ACLs, so it might be usable. Tom, Bruce?
Regards,
Andreas
---(end of broadcast)---
TIP 6: Have you searched our
Andreas Pflug wrote:
Sergio A. Kessler wrote:
Too sad, all special chars are used up for operators
also '{' '}' are used ?
I've only seen this in ACLs, so it might be usable. Tom, Bruce?
Something that includes ' would be clearest. I thought of ' and ',
but this would break:
Bruce Momjian wrote:
Something that includes ' would be clearest. I thought of ' and ',
but this would break:
I'm not sure that using a quote is necessarily clearest. But it's a
matter of taste. I had thought of {{ and }} as maybe working.
[snip]
One clean way would be to use {' to start a
Bruce Momjian [EMAIL PROTECTED] writes:
Something that includes ' would be clearest. I thought of ' and ',
but this would break:
if var 'yes'
People seem to be assuming that this feature needs to be impervious to
whitespace and being adjacent to other things. I believe we could make
it
On Thu, 11 Sep 2003, Tom Lane wrote:
People seem to be assuming that this feature needs to be impervious to
whitespace and being adjacent to other things. I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish I had a $ for
every time that has made my life difficult.
cheers
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish I had a $ for
every time
Jon Jensen [EMAIL PROTECTED] writes:
Is there a reason not to use here documents?
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents. We cannot use exactly the shell syntax for
here-documents, though, mainly because we already have meaning assigned
to strings
Bruce Momjian wrote:
Sounds good. I just think keywords in general are weird to use for
quoting. We use ' for quoting, so something similar like another
operator combination would be nice. I have never been fond of the
here-document approach, though I can see the value of doing
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish I
Andreas Pflug wrote:
solution would be a great enhancement, details are now merely a question
of taste.
While this sounds nearly done for me, as there seems some fundamental
consense, I'll will probably have to wait for 7.5?
Yes, has to wait for 7.5.
--
Bruce Momjian
Jan Wieck wrote:
Bruce Momjian wrote:
Sounds good. I just think keywords in general are weird to use for
quoting. We use ' for quoting, so something similar like another
operator combination would be nice. I have never been fond of the
here-document approach, though I can see the
Tom Lane wrote:
Jon Jensen [EMAIL PROTECTED] writes:
Is there a reason not to use here documents?
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents. We cannot use exactly the shell syntax for
here-documents, though, mainly because we already have meaning
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Sounds good. I just think keywords in general are weird to use for
quoting. We use ' for quoting, so something similar like another
operator combination would be nice. I have never been fond of the
here-document approach, though
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents.
Couldn't we allow at the beginning of the line to mean 'here' document?
No; you could easily be breaking existing queries, for example
regression=#
Jan Wieck wrote:
The beauty of here-documents is that you specify your closing tag on a
per usage base and can vary that depending on the content you need to
enclose. Keep in mind that this literal mechanism is not only used for
PL/pgSQL, but for other languages like PL/Tcl and PL/Perl
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents.
Couldn't we allow at the beginning of the line to mean 'here' document?
No; you could easily be breaking existing queries, for
On Thu, 11 Sep 2003, Bruce Momjian wrote:
I would definitely like to see us adopt a proposal that is like
here-documents to the extent that there's a family of possible
terminator markers and not only one. But we'll have to adjust the
syntax a little bit. If you don't like $$FOO, what
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, that is true. I didn't like the beginning-of-line requirement for
here documents for that reason. However, we are already requiring the
thing to be at the beginning of the line. You are saying it is safer to
make it at the beginnning of a line
Bruce Momjian [EMAIL PROTECTED] writes:
So you are requiring the identical text to appear at the beginning and
end of the quote, rather than a here document that would be:
END
...
END
or in your example:
$$END
...
END
Yes, I was thinking of
Jon Jensen wrote:
On Thu, 11 Sep 2003, Bruce Momjian wrote:
I would definitely like to see us adopt a proposal that is like
here-documents to the extent that there's a family of possible
terminator markers and not only one. But we'll have to adjust the
syntax a little bit. If you
Bruce Momjian writes:
Tom Lane wrote:
Jon Jensen [EMAIL PROTECTED] writes:
Is there a reason not to use here documents?
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents. We cannot use exactly the shell syntax for
here-documents, though, mainly
On Thu, 11 Sep 2003, Tom Lane wrote:
It is possible that we could allow the start marker to be not at the
beginning of its line, which would create structures very very close
to shell here-documents:
CREATE FUNCTION foo() RETURNS int AS $$FUNCTION
... text here ...
Tilo Schwarz [EMAIL PROTECTED] writes:
What about the Python approach: The literal text is enclosed either in a pair
of three single quotes or three double quotes.
That might be okay if we were working in a vacuum, but we aren't. Among
other things, the SQL spec tells us what 'quote''' ...
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
So you are requiring the identical text to appear at the beginning and
end of the quote, rather than a here document that would be:
END
...
END
or in your example:
$$END
...
END
Yes, I was thinking of
Bruce Momjian [EMAIL PROTECTED] writes:
... You are saying it is safer to
make it at the beginnning of a line _and_ have it be something that
isn't used in SQL, but $$ is used in Perl, so I don't see the big
advantage either way --- once you say X has to begin at the beginning of
the line, we
Tom Lane wrote:
Keep in mind that we have two different requirements: the quote start
marker has to be recognizable while we are parsing SQL (or possibly
plpgsql) code. The quote end marker has to be recognizable while we are
scanning text that could be almost anything.
The cute thing
Sean Chittenden [EMAIL PROTECTED] writes:
Let me jump in for half a second here (no pun intended), but what
about the use of back quotes? ` `? Use a very limited escaping policy
of \` = ` and \\ = \ .
Actually, having to double backslashes is one of the things I want to
get rid of. The
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
---
Many discussions, but no final conclusion in sight, it seems. That
\beginliteral stuff is psql
On Wed, Sep 10, 2003 at 07:04:13PM +0200, Andreas Pflug wrote:
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight, it seems. That
\beginliteral stuff is psql centric,
Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 07:04:13PM +0200, Andreas Pflug wrote:
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight, it seems. That
On Wed, Sep 10, 2003 at 07:04:13PM +0200, Andreas Pflug wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight, it seems. That
\beginliteral stuff is psql centric, where a sql syntax
Andrew Dunstan wrote:
Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 07:04:13PM +0200, Andreas Pflug wrote:
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight,
On Wed, Sep 10, 2003 at 10:35:18PM +0200, Andreas Pflug wrote:
I never agreed that a client solution would be satisfying. While
frontends might try to hide some uglyness of the syntax to the user for
single functions, editing large scripts with many functions is still
suffering from
Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 10:35:18PM +0200, Andreas Pflug wrote:
I never agreed that a client solution would be satisfying. While
frontends might try to hide some uglyness of the syntax to the user for
single functions, editing large scripts with many functions is still
On Wed, 10 Sep 2003, Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 10:35:18PM +0200, Andreas Pflug wrote:
I never agreed that a client solution would be satisfying. While
frontends might try to hide some uglyness of the syntax to the user for
single functions, editing large scripts
Jon Jensen [EMAIL PROTECTED] writes:
On Wed, 10 Sep 2003, Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 10:35:18PM +0200, Andreas Pflug wrote:
I never agreed that a client solution would be satisfying. While
frontends might try to hide some uglyness of the syntax to the user for
Greg Stark wrote:
Could the function bodies be shipped over using the new FE protocol as
parameters? That would eliminate the quoting and simplify matters for DBI and
other drivers as well.
Oh no, not this discussion again.
A whole script containing any number of valid statements must be
On Thu, Sep 11, 2003 at 01:05:47AM +0200, Andreas Pflug wrote:
Greg Stark wrote:
Could the function bodies be shipped over using the new FE protocol as
parameters? That would eliminate the quoting and simplify matters for DBI
and other drivers as well.
Oh no, not this discussion again.
Alvaro Herrera [EMAIL PROTECTED] writes:
On Thu, Sep 11, 2003 at 01:05:47AM +0200, Andreas Pflug wrote:
A whole script containing any number of valid statements must be
executable without interpreting the script.
How is that relevant? It's still parseable with parameter placeholders in
Andreas Pflug wrote:
I never agreed that a client solution would be satisfying. While
frontends might try to hide some uglyness of the syntax to the user
for single functions, editing large scripts with many functions is
still suffering from massive quotes.
Yes, I agree that a psql-specific
Jon Jensen [EMAIL PROTECTED] writes:
On Wed, 10 Sep 2003, Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 10:35:18PM +0200, Andreas Pflug wrote:
I never agreed that a client solution would be satisfying. While
frontends might try to hide some uglyness of the syntax to the user for
Andreas Pflug [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight, it seems. That
\beginliteral stuff is psql centric, where a sql syntax solution
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
---
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
In that case, though, the solution will presumably look at
I think if it could be done in a reasonably aesthetic way in psql that
would satisfy many people, without any need to disturb the backend,
which Tom objects to.
That's a big if, IMNSHO :-).
I'd hate to see this dropped, though
cheers
andrew
Bruce Momjian wrote:
I assume we never came to a
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Another problem is that the CREATE FUNCTION syntax doesn't insist on any
particular ordering of the attributes;
This is so at the moment, while all samples use AS LANGUAGE. This
could stay free format if quoted as usual, and
Tom Lane wrote:
Considering that someone earlier in this thread was specifically asking
to put LANGUAGE before the function body (apparently unaware that he
already could), I doubt we can get away with removing that flexibility.
I didn't consider *removing* flexibility, but *adding*
Tom Lane wrote:
Considering that someone earlier in this thread was specifically asking
to put LANGUAGE before the function body (apparently unaware that he
already could), I doubt we can get away with removing that flexibility.
That was me, and I'm glad to see you can do it. I guess I
Tom Lane wrote:
psql may indeed work with no changes, because it's too stupid to know
when you're defining a function, and so it would not be surprised to get
a Start Copy In back from a CREATE FUNCTION command. This would not be
true of nearly any other client that one might use to define a
Andreas Pflug [EMAIL PROTECTED] writes:
But we're not talking about psql only (and \beginlit and \endlit are
quite ugly sql keywords), and this should be a backend thing only
I disagree with both of those assertions. psql is the issue because
other clients used for administrative work
Andrew Dunstan [EMAIL PROTECTED] writes:
Frontends would not be forced to use something that triggered this -
after all we have to stay backwards compatible and support the existing
inline string, no?
Certainly. I didn't see anyone proposing to break backwards
compatibility.
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm also wondering why the backend need have anything at all to do with
an improved function-definition mode. If you look in the archives you
will see speculation about inventing psql backslash commands that would
assist in entering
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm also wondering why the backend need have anything at all to do with
an improved function-definition mode. If you look in the archives you
will see speculation about inventing psql backslash commands that would
Andrew Dunstan [EMAIL PROTECTED] writes:
In that case, though, the solution will presumably look at least a bit
different from those discussed so far in this thread. Or would you have
psql detect that in place of a string there was stdin or whatever and
then replace it with the inline
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
In that case, though, the solution will presumably look at least a bit
different from those discussed so far in this thread. Or would you have
psql detect that in place of a string there was stdin or whatever and
then replace it
1 - 100 of 119 matches
Mail list logo
