On Tue, Sep 15, 2009 at 07:38:18AM +0200, Pavel Stehule wrote:
it isn't fair :) why you use $$ without single quote? And still this
case should be vulnerable on SQL injection. Maybe you or me knows,
what SQL injection means, but beginners knows nothing and this people
use following bad code:
On Sep 14, 2009, at 12:13 AM, Pavel Stehule wrote:
2009/9/13 decibel deci...@decibel.org:
On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
decibel wrote:
Speaking of concatenation...
Something I find sorely missing in plpgsql is the ability to put
variables inside of a string, ie:
2009/9/14 decibel deci...@decibel.org:
On Sep 14, 2009, at 12:13 AM, Pavel Stehule wrote:
2009/9/13 decibel deci...@decibel.org:
On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
decibel wrote:
Speaking of concatenation...
Something I find sorely missing in plpgsql is the ability to
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
How is it any worse than what people can already do? Anyone who isn't aware
of the dangers of SQL injection has already screwed themselves. You're
basically arguing that they would put a variable inside of quotes, but
2009/9/14 Merlin Moncure mmonc...@gmail.com:
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
How is it any worse than what people can already do? Anyone who isn't aware
of the dangers of SQL injection has already screwed themselves. You're
basically arguing that
On Sep 14, 2009, at 1:02 PM, Pavel Stehule wrote:
2009/9/14 Merlin Moncure mmonc...@gmail.com:
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule
pavel.steh...@gmail.com wrote:
How is it any worse than what people can already do? Anyone who
isn't aware
of the dangers of SQL injection has
2009/9/15 decibel deci...@decibel.org:
On Sep 14, 2009, at 1:02 PM, Pavel Stehule wrote:
2009/9/14 Merlin Moncure mmonc...@gmail.com:
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
How is it any worse than what people can already do? Anyone who isn't
aware
Hello
ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
are much more SQL-like than needing to write any or anyelement(n) as
argument type or return type
I looked on possibilities in gram.y and I thing, type identifiers
ANY TYPE is possible without any problems (this
On Sun, 2009-09-13 at 21:50 +0200, Pavel Stehule wrote:
Hello
ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
are much more SQL-like than needing to write any or anyelement(n) as
argument type or return type
I looked on possibilities in gram.y and I thing,
On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
decibel wrote:
Speaking of concatenation...
Something I find sorely missing in plpgsql is the ability to put
variables inside of a string, ie:
DECLARE
v_table text := ...
v_sql text;
BEGIN
v_sql := SELECT * FROM $v_table;
Of course, I'm
2009/9/13 decibel deci...@decibel.org:
On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
decibel wrote:
Speaking of concatenation...
Something I find sorely missing in plpgsql is the ability to put
variables inside of a string, ie:
DECLARE
v_table text := ...
v_sql text;
BEGIN
v_sql
2009/9/13 Hannu Krosing ha...@2ndquadrant.com:
On Sun, 2009-09-13 at 21:50 +0200, Pavel Stehule wrote:
Hello
ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
are much more SQL-like than needing to write any or anyelement(n) as
argument type or return type
I
On Sep 11, 2009, at 10:19 AM, Robert Haas wrote:
On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I think the main benefit of a sprintf type function for
PostgreSQL is
in the formatting (setting length, scale, alignment),
On Fri, Sep 11, 2009 at 11:43:32AM -0400, Merlin Moncure wrote:
If you are going to use printf format codes, which is good and useful
being something of a standard, I'd call routine printf (not format)
and actually wrap vsnprintf. The format codes in printf have a very
specific meaning:
decibel wrote:
Speaking of concatenation...
Something I find sorely missing in plpgsql is the ability to put
variables inside of a string, ie:
DECLARE
v_table text := ...
v_sql text;
BEGIN
v_sql := SELECT * FROM $v_table;
Of course, I'm assuming that if it was easy to do that it would
* Alvaro Herrera alvhe...@commandprompt.com [090910 23:32]:
Is this really all that hard? I'm thinking it could be implemented by
using the real C sprintf underneath, passing one % specifier and its
corresponding parameter at a time, coerced to whatever the conversion
specifier specifies.
On Thu, 2009-09-10 at 19:52 +0200, Pavel Stehule wrote:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
alvherre=# select text_format('% was % at % and said % % times',
'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
Kevin Grittner escribió:
Pavel Stehule pavel.steh...@gmail.com wrote:
what is more readable?
select 'i=' || i || ', b=' || b || ', c=' || c ..
or
select format('i=%, b=%, c=%', i, b, c ..)
Seriously, those are about dead even for me. The concatenation
might have a slight
Alvaro Herrera alvhe...@commandprompt.com wrote:
the format version is a lot better than the || alternative.
Well, if you're trying to tell me what is easier for me to read,
you're probably wrong. I won't presume to try to tell you what you
find easier to read.
I think the main benefit of
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I think the main benefit of a sprintf type function for PostgreSQL is
in the formatting (setting length, scale, alignment), not in making
concatenation more pretty.
Exactly, which is why I'm so distressed that this proposal not only
hasn't got
Alvaro Herrera alvhe...@commandprompt.com writes:
Is this really all that hard? I'm thinking it could be implemented by
using the real C sprintf underneath, passing one % specifier and its
corresponding parameter at a time, coerced to whatever the conversion
specifier specifies.
The only
On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I think the main benefit of a sprintf type function for PostgreSQL is
in the formatting (setting length, scale, alignment), not in making
concatenation more pretty.
Robert Haas robertmh...@gmail.com writes:
I like the idea of making concatenation more pretty, quite frankly.
No one has really responded to Pavel's contention that this is what
to_char() is for.
[ shrug... ] I regard this as a prettier replacement for to_char.
That thing has got nothing
On Fri, Sep 11, 2009 at 11:19 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I think the main benefit of a sprintf type function for PostgreSQL is
in the formatting (setting
On Fri, Sep 11, 2009 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Is this really all that hard? I'm thinking it could be implemented by
using the real C sprintf underneath, passing one % specifier and its
corresponding parameter at a time,
Merlin Moncure mmonc...@gmail.com writes:
If you are going to use printf format codes, which is good and useful
being something of a standard, I'd call routine printf (not format)
and actually wrap vsnprintf. The format codes in printf have a very
specific meaning: converting native C types
On Fri, Sep 11, 2009 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
If you are going to use printf format codes, which is good and useful
being something of a standard, I'd call routine printf (not format)
and actually wrap vsnprintf. The format
2009/9/11 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
If you are going to use printf format codes, which is good and useful
being something of a standard, I'd call routine printf (not format)
and actually wrap vsnprintf. The format codes in printf have a very
On Thu, 2009-09-10 at 08:44 +0300, Hannu Krosing wrote:
maybe just let users say what they mean, so first time we have any and
if we need more then we say same_as(...)
Acutually we could be even more SQL-y and have a more verbose syntax for
pseudotypes by extending the grammar
CREATE
On Wed, 2009-09-09 at 16:31 -0400, Tom Lane wrote:
The immediate practical problem is
that we don't store a typmod for function argument/result types.
I guess we could look into doing that ...
I think that functionality could also end up being useful for other
types.
--
Sent via
2009/9/10 Hannu Krosing ha...@krosing.net:
On Thu, 2009-09-10 at 08:44 +0300, Hannu Krosing wrote:
maybe just let users say what they mean, so first time we have any and
if we need more then we say same_as(...)
Acutually we could be even more SQL-y and have a more verbose syntax for
Robert Haas robertmh...@gmail.com wrote:
There are languages much less obscure than Haskell that support
passing functions as arguments to other functions, such as C.
Or Java, which lets you, for example, pass a Class or Method as an
argument, and includes support for generics.
I see that
Pavel Stehule escribió:
Please, try to compile and run sprintf function from attachment
There's a minor bug in the comparison to PG_NARGS() inside the loop,
fixed in this version.
The one problem I have with this is that if the format string does not
contain any % (and thus there is no extra
Alvaro Herrera alvhe...@commandprompt.com writes:
alvherre=# select text_format('% was % at % and said % % times',
'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
text_format
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
Is that what's being proposed?
I think that's what currently works, given the limitations of arrays
(variadic arguments) to a single data type.
That pretty much sucks --- it's just
another way of concatenating some strings. I thought the
David E. Wheeler da...@kineticode.com writes:
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
Is that what's being proposed?
I think that's what currently works, given the limitations of arrays
(variadic arguments) to a single data type.
Well, at the very least the parameter markers should
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
alvherre=# select text_format('% was % at % and said % % times',
'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
text_format
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
David E. Wheeler da...@kineticode.com writes:
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
Is that what's being proposed?
I think that's what currently works, given the limitations of arrays
(variadic arguments) to a single data type.
no, in my code
2009/9/10 David E. Wheeler da...@kineticode.com:
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
Is that what's being proposed?
I think that's what currently works, given the limitations of arrays
(variadic arguments) to a single data type.
That pretty much sucks --- it's just
another way
Pavel Stehule pavel.steh...@gmail.com writes:
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
I thought the idea was to
provide the same power as sprintf, eg field width controls, numeric
formatting options, etc.
no - we have to_char function, why we need different formatting system?
Why do
On Sep 10, 2009, at 11:16 AM, Tom Lane wrote:
no - we have to_char function, why we need different formatting
system?
Why do we need this at all, when we have the concatenation operator?
I think the point of it is that people are used to how sprintf works.
So it should work as nearly like
On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Really, I think we need a type system that doesn't try to represent
every type as a 32-bit integer. Right now, for example, there's no
reasonable way to write a function that takes another function as an
argument.
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
I thought the idea was to
provide the same power as sprintf, eg field width controls, numeric
formatting options, etc.
no - we have to_char function, why we
2009/9/10 Robert Haas robertmh...@gmail.com:
On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Really, I think we need a type system that doesn't try to represent
every type as a 32-bit integer. Right now, for example, there's no
reasonable way to write a function
Robert Haas robertmh...@gmail.com writes:
The major downside of such a system is that every place where we now
count on being able to store a type in a fixed-size field would need
to be touched. I don't believe that the overall slowdown in parsing
time would be significant, but I do think it
Pavel Stehule pavel.steh...@gmail.com wrote:
what is more readable?
select 'i=' || i || ', b=' || b || ', c=' || c ..
or
select format('i=%, b=%, c=%', i, b, c ..)
Seriously, those are about dead even for me. The concatenation
might have a slight edge, particularly since I have the
Pavel Stehule pavel.steh...@gmail.com writes:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
I think the point of it is that people are used to how sprintf works.
So it should work as nearly like sprintf as possible.
How sprintf will be print bytea type, or char(n) type values?
Well, that's why it
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
I think the point of it is that people are used to how sprintf works.
So it should work as nearly like sprintf as possible.
How sprintf will be print bytea type, or
On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The major downside of such a system is that every place where we now
count on being able to store a type in a fixed-size field would need
to be touched. I don't believe that the
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
I think the point of it is that people are used to how sprintf works.
So it should work as nearly like sprintf as possible.
How sprintf will be print bytea type, or
Pavel Stehule pavel.steh...@gmail.com writes:
I don't afraid about crashing. Simply I have not idea what sql
sprintf's behave in case:
SELECT sprintf('some %s', 10)
That one I don't think is hard --- coerce the input type to text and
print the string.
SELECT sprintf('some %d',
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
2. Come up with some way to do the equivalent of variadic any[],
ie, a variable number of not-all-the-same-type arguments. (This isn't
just a type-system problem, there's also the
good analyse, thank you
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
The major downside of such a system is that every place where we now
count on being able to store a type in a fixed-size field would need
to be touched. I don't believe that the overall
Pavel Stehule pavel.steh...@gmail.com writes:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
1. Allow the existing any pseudotype as an input argument type for PLs.
(AFAICS this is simple and painless; about the only question is whether
we want to keep using the name any, which because of conflicting
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
1. Allow the existing any pseudotype as an input argument type for PLs.
(AFAICS this is simple and painless; about the only question is whether
we want to keep using the
On Thu, Sep 10, 2009 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
2. Come up with some way to do the equivalent of variadic any[],
ie, a variable number of not-all-the-same-type
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I don't afraid about crashing. Simply I have not idea what sql
sprintf's behave in case:
SELECT sprintf('some %s', 10)
That one I don't think is hard --- coerce the input type to text and
print the string.
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
It might be possible to make it work, but it's likely to create a lot
of bloat in pg_type, and will make it very difficult to implement
features such as anonymous functions (i.e. LAMBDA).
For
On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
1. Allow the existing any pseudotype as an input argument type for PLs.
(AFAICS this is simple and painless;
On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I don't afraid about crashing. Simply I have not idea what sql
sprintf's behave in case:
SELECT sprintf('some %s', 10)
That one I don't think
On Sep 10, 2009, at 12:10 PM, Tom Lane wrote:
SELECT sprintf('some %d', 10::mycustomtype)
For the formats that presume an integer or float input in C, perhaps
we could coerce to numeric (failing if that fails) and then print
appropriately. Or maybe int or float8 would be more appropriate
2009/9/10 Hannu Krosing ha...@krosing.net:
On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
1. Allow the existing any pseudotype as an input argument type for
2009/9/10 Hannu Krosing ha...@2ndquadrant.com:
On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I don't afraid about crashing. Simply I have not idea what sql
sprintf's behave in case:
SELECT
There is actualised version, for people who are interested on it.
Minimally it should be sample of variadic any function for playing.
Don't afraid, I don't plan to send it to commit fest.
regards
Pavel
2009/9/10 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
Please, try to
Hannu Krosing ha...@2ndquadrant.com writes:
5. Various syntactic sugar to substitute for anyelement. (Not in favor
of this myself, it seems to just complicate matters.)
I agree; I don't think this solves any real problem.
agreed, it does not solve the underlying problem, just may make it
On Thu, 2009-09-10 at 22:15 +0200, Pavel Stehule wrote:
2009/9/10 Hannu Krosing ha...@2ndquadrant.com:
On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
2009/9/10 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I don't afraid about crashing. Simply I
* Pavel Stehule pavel.steh...@gmail.com [090910 16:16]:
first is coming from C and has C semantic - there is only one possible
tag (without binary compatible types) - you cannot use %s for numbers,
and %d for strings is some specific value.
sprintf(%d, 10) - show address of static string
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
It might be possible to make it work, but it's likely to create a lot
of bloat in pg_type, and will make it very difficult to implement
2009/9/10 Dimitri Fontaine dfonta...@hi-media.com:
Hannu Krosing ha...@2ndquadrant.com writes:
5. Various syntactic sugar to substitute for anyelement. (Not in favor
of this myself, it seems to just complicate matters.)
I agree; I don't think this solves any real problem.
agreed, it does
On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
It might be possible to make it work, but it's likely to create a
On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/9/10 Dimitri Fontaine dfonta...@hi-media.com:
Hannu Krosing ha...@2ndquadrant.com writes:
5. Various syntactic sugar to substitute for anyelement. (Not in favor
of this myself, it seems to just complicate
On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
It might
2009/9/10 Robert Haas robertmh...@gmail.com:
On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/9/10 Dimitri Fontaine dfonta...@hi-media.com:
Hannu Krosing ha...@2ndquadrant.com writes:
5. Various syntactic sugar to substitute for anyelement. (Not in favor
2009/9/10 Hannu Krosing ha...@2ndquadrant.com:
On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu,
On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The major downside of such a system is that every place where we now
count on being able to store a type in a fixed-size field
On Sep 10, 2009, at 2:08 PM, Hannu Krosing wrote:
Perhaps you should try changing ANY to a non-reserved word in the
parser and see what happens. If you come up with a way to resolve
the
shift/reduce and/or reduce/reduce conflicts that will probably
result,
submit a patch.
I don't want
On Thu, Sep 10, 2009 at 5:08 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com
Aidan Van Dyk escribió:
Just to make the task that much harder, if PostgreSQL is going to have a
sprintf (in core, or contrib), I *really* hope it's a real sprintf,
supporting everything, like:
$m positional notation
* width argument
All the flags [#0- +'] (I as a bonus)
field
2009/9/11 Alvaro Herrera alvhe...@commandprompt.com:
Aidan Van Dyk escribió:
Just to make the task that much harder, if PostgreSQL is going to have a
sprintf (in core, or contrib), I *really* hope it's a real sprintf,
supporting everything, like:
$m positional notation
* width
On Tue, 2009-09-08 at 10:23 -0700, David E. Wheeler wrote:
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same type,
otherwise there is no certainty that that means anything at all.
Yes, for the
Peter Eisentraut wrote:
On Tue, 2009-09-08 at 10:23 -0700, David E. Wheeler wrote:
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same type,
otherwise there is no certainty that that means
On Wed, 2009-09-09 at 07:47 -0400, Alvaro Herrera wrote:
Peter Eisentraut wrote:
On Tue, 2009-09-08 at 10:23 -0700, David E. Wheeler wrote:
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same
Peter Eisentraut pete...@gmx.net writes:
Well, so far we've only seen use cases in this thread that either
already work or that are not well-defined. ;-)
Well, yeah, the question is can we extract a clear TODO item here.
I think there are two somewhat orthogonal issues:
1. Is a completely
2009/9/9 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net writes:
Well, so far we've only seen use cases in this thread that either
already work or that are not well-defined. ;-)
Well, yeah, the question is can we extract a clear TODO item here.
I think there are two somewhat
On Sep 9, 2009, at 6:39 AM, Tom Lane wrote:
1. Is a completely unconstrained argument type (ie any) of any real
use to PL functions, and if so how can we expose that usefulness?
The only clear thing to do with such an argument is IS NULL/IS NOT
NULL
tests, which might or might not be worth
On Sep 9, 2009, at 8:39 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Well, so far we've only seen use cases in this thread that either
already work or that are not well-defined. ;-)
Well, yeah, the question is can we extract a clear TODO item here.
I think there are two
David E. Wheeler da...@kineticode.com writes:
On Sep 9, 2009, at 6:39 AM, Tom Lane wrote:
1. Is a completely unconstrained argument type (ie any) of any real
use to PL functions, and if so how can we expose that usefulness?
The only clear thing to do with such an argument is IS NULL/IS NOT
On Sep 9, 2009, at 10:04 AM, Tom Lane wrote:
Well, yeah: it looks like a fertile source of security holes, not to
mention implementation difficulties (plpgsql really wants well-typed
expressions...). What you can do at the C level is not necessarily
sane to give to PL authors. I'm willing to
Tom Lane wrote:
In an example like
create function foo (anyelement, anyelement2, anyelement2)
returns anyarray2
the second and third arguments would be tied to be of the same type,
and the result would be an array of that type; whereas the first
argument's type is unrelated.
Alvaro Herrera alvhe...@commandprompt.com writes:
Another possible example is sprintf:
create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
returns text
In order for this to work in general, we'd need FUNC_MAX_ARGS different
types, which is currently defined as 100 in
On Sep 9, 2009, at 10:15 AM, Tom Lane wrote:
In order for this to work in general, we'd need FUNC_MAX_ARGS
different
types, which is currently defined as 100 in our code.
But here, any would work perfectly fine, since there's no need for
any two arguments to be tied to each other or the
David E. Wheeler da...@kineticode.com writes:
On Sep 9, 2009, at 10:04 AM, Tom Lane wrote:
Well, yeah: it looks like a fertile source of security holes, not to
mention implementation difficulties (plpgsql really wants well-typed
expressions...). What you can do at the C level is not
David E. Wheeler da...@kineticode.com writes:
On Sep 9, 2009, at 10:15 AM, Tom Lane wrote:
But here, any would work perfectly fine, since there's no need for
any two arguments to be tied to each other or the result.
Well, only if you write your functions in C. I'd like to be able to
write
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Another possible example is sprintf:
create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
returns text
In order for this to work in general, we'd need FUNC_MAX_ARGS different
types, which is
On Sep 9, 2009, at 10:17 AM, Tom Lane wrote:
Well, none, *if* it's defined to have exactly the same runtime
behavior
as anyelement does. It sounded like you were arguing for something
looser. We could certainly define it as being just like anyelement
but not constrained to match any other
Alvaro Herrera alvhe...@commandprompt.com writes:
BTW does any match other pseudotypes? Would I be able to pass a
cstring into any? That would create a large security hole I think.
How so? 'Cause you can do that now with anyelement.
cstring is only a pseudotype for historical reasons,
On Sep 9, 2009, at 10:22 AM, Tom Lane wrote:
Well, only if you write your functions in C. I'd like to be able to
write sprintf() in PL/pgSQL. Or PL/Perl, for that matter.
I think you're confusing the point with a secondary issue, which is
what
access we provide to these pseudotypes in PLs.
David E. Wheeler da...@kineticode.com writes:
Yes, that sounds about right. Is that not basically what Alvaro was
looking for to start with? And is there an any array that could work
for variadic functions like sprintf(), as well?
Well, no, because arrays are inherently all the same
2009/9/9 David E. Wheeler da...@kineticode.com:
On Sep 9, 2009, at 10:17 AM, Tom Lane wrote:
Well, none, *if* it's defined to have exactly the same runtime behavior
as anyelement does. It sounded like you were arguing for something
looser. We could certainly define it as being just like
2009/9/9 Tom Lane t...@sss.pgh.pa.us:
David E. Wheeler da...@kineticode.com writes:
Yes, that sounds about right. Is that not basically what Alvaro was
looking for to start with? And is there an any array that could work
for variadic functions like sprintf(), as well?
Well, no, because
1 - 100 of 139 matches
Mail list logo
