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
2009/9/15 decibel :
>
> On Sep 14, 2009, at 1:02 PM, Pavel Stehule wrote:
>
>> 2009/9/14 Merlin Moncure :
>>>
>>> On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule
>>> wrote:
>
> How is it any worse than what people can already do? Anyone who isn't
> aware
> of the dangers of SQL inje
On Sep 14, 2009, at 1:02 PM, Pavel Stehule wrote:
2009/9/14 Merlin Moncure :
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule
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
2009/9/14 Merlin Moncure :
> On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule
> 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 insi
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule 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 they
>> would nev
2009/9/14 decibel :
> On Sep 14, 2009, at 12:13 AM, Pavel Stehule wrote:
>>
>> 2009/9/13 decibel :
>>>
>>> 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 pu
On Sep 14, 2009, at 12:13 AM, Pavel Stehule wrote:
2009/9/13 decibel :
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 := .
2009/9/13 Hannu Krosing :
> 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
2009/9/13 decibel :
> 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;
>
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
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 a
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
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
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:
On Sep 11, 2009, at 10:19 AM, Robert Haas wrote:
On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane wrote:
"Kevin Grittner" 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.
2009/9/11 Tom Lane :
> Merlin Moncure 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 nati
On Fri, Sep 11, 2009 at 12:11 PM, Tom Lane wrote:
> Merlin Moncure 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
>> spe
Merlin Moncure 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 to arrays of cha
On Fri, Sep 11, 2009 at 10:38 AM, Tom Lane wrote:
> Alvaro Herrera 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
>>
On Fri, Sep 11, 2009 at 11:19 AM, Robert Haas wrote:
> On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane wrote:
>> "Kevin Grittner" 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
Robert Haas 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 whatsoever to recommend
On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane wrote:
> "Kevin Grittner" 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 th
Alvaro Herrera 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 disadvantage I can see of
"Kevin Grittner" 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 that, but is designed
Alvaro Herrera 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 a sprintf type function fo
Kevin Grittner escribió:
> Pavel Stehule 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
On Thu, 2009-09-10 at 19:52 +0200, Pavel Stehule wrote:
> 2009/9/10 Tom Lane :
> > Alvaro Herrera writes:
> >> alvherre=# select text_format('% was % at % and said % % times',
> >> 'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
> >> text_
* Alvaro Herrera [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.
It's not "hard", but pl
2009/9/11 Alvaro Herrera :
> 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
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)
>
On Thu, Sep 10, 2009 at 5:08 PM, Hannu Krosing wrote:
> On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
>> On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
>> > On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
>> >> Hannu Krosing writes:
>> >> > On Thu, 2009-09-10 at 15:06 -0400, Ro
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 it
On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane wrote:
> > Robert Haas 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.
2009/9/10 Hannu Krosing :
> On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
>> On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
>> > On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
>> >> Hannu Krosing writes:
>> >> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
>> >> >> It
2009/9/10 Robert Haas :
> On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule
> wrote:
>> 2009/9/10 Dimitri Fontaine :
>>> Hannu Krosing writes:
> > 5. Various syntactic sugar to substitute for anyelement. (Not in favor
> > of this myself, it seems to just complicate matters.)
>
> I
On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
> > On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> >> Hannu Krosing writes:
> >> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> >> >> It might be possible to make it work
On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule wrote:
> 2009/9/10 Dimitri Fontaine :
>> Hannu Krosing 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 an
On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
> On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
>> Hannu Krosing 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
2009/9/10 Dimitri Fontaine :
> Hannu Krosing 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
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> Hannu Krosing 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
* Pavel Stehule [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 "10"
>
> second
On Thu, 2009-09-10 at 22:15 +0200, Pavel Stehule wrote:
> 2009/9/10 Hannu Krosing :
> > On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
> >> 2009/9/10 Tom Lane :
> >> > Pavel Stehule writes:
> >> >> I don't afraid about crashing. Simply I have not idea what sql
> >> >> sprintf's behave in
Hannu Krosing 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
> easier
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 :
> Pavel Stehule escribió:
>
>> Please, try to compile and run spri
2009/9/10 Hannu Krosing :
> On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
>> 2009/9/10 Tom Lane :
>> > Pavel Stehule 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
2009/9/10 Hannu Krosing :
> On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
>> 2009/9/10 Tom Lane :
>> > Pavel Stehule writes:
>> >> 2009/9/10 Tom Lane :
>> >>> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
>> >>> (AFAICS this is simple and painless; about the o
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
conv
On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
> 2009/9/10 Tom Lane :
> > Pavel Stehule 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 i
On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
> 2009/9/10 Tom Lane :
> > Pavel Stehule writes:
> >> 2009/9/10 Tom Lane :
> >>> 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
Hannu Krosing 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 functions, anon
2009/9/10 Tom Lane :
> Pavel Stehule 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',
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>> 2009/9/10 Tom Lane :
>>> 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 with
On Thu, Sep 10, 2009 at 3:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane 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 prob
Pavel Stehule writes:
> 2009/9/10 Tom Lane :
>> 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 with
>> a reserved word would a
good analyse, thank you
2009/9/10 Tom Lane :
> Robert Haas 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
Robert Haas writes:
> On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane 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 question of how the type
>> inform
Pavel Stehule 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', 10::mycustomtype)
For the format
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>> 2009/9/10 Tom Lane :
>>> 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 requir
On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane wrote:
> Robert Haas 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 wo
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>> 2009/9/10 Tom Lane :
>>> 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 requir
Pavel Stehule writes:
> 2009/9/10 Tom Lane :
>> 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 requires some actual thought and agre
Pavel Stehule 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 option, if
it get
Robert Haas 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 would be a massive
2009/9/10 Robert Haas :
> On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule 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
>>
2009/9/10 Tom Lane :
> Pavel Stehule 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
On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule 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. What we need is a
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 spr
Pavel Stehule 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 we need this
2009/9/10 David E. Wheeler :
> 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 concate
2009/9/10 Tom Lane :
> "David E. Wheeler" 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 is nothing transformed to s
2009/9/10 Tom Lane :
> Alvaro Herrera writes:
>> alvherre=# select text_format('% was % at % and said % % times',
>> 'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
>> text_format
>>
"David E. Wheeler" 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 be spelled "%s"
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 idea
Alvaro Herrera writes:
> alvherre=# select text_format('% was % at % and said % % times',
> 'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
> text_format
> --
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 a
Robert Haas 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 pgfoundry has pl/Jav
2009/9/10 Hannu Krosing :
> 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
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 pgsql-hac
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 FU
On Thu, 2009-09-10 at 00:31 +0200, Dimitri Fontaine wrote:
> Hi,
>
> Tom Lane writes:
> > Hannu Krosing writes:
> >> anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
> >> the number in parentheses
> >
> > Yeah, that idea occurred to me too. The immediate practical problem
On Wed, Sep 9, 2009 at 3:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> What we need is a system where base types are represented
>> by an OID, but derived types (list and functional types) are built up
>> using type constructors that take other types as arguments.
>
> This is SQL, not Haskell.
Hi,
Tom Lane writes:
> Hannu Krosing writes:
>> anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
>> the number in parentheses
>
> Yeah, that idea occurred to me too. The immediate practical problem is
> that we don't store a typmod for function argument/result types.
> I
On Sep 9, 2009, at 2:36 PM, Alvaro Herrera wrote:
Robert Haas escribió:
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.
Functi
On Wed, Sep 09, 2009 at 03:23:52PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > What we need is a system where base types are represented
> > by an OID, but derived types (list and functional types) are built up
> > using type constructors that take other types as arguments.
>
> This is SQL,
On Wed, 2009-09-09 at 21:57 +0200, Pavel Stehule wrote:
> 2009/9/9 Alvaro Herrera :
> > Pavel Stehule escribió:
> >> 2009/9/9 Alvaro Herrera :
> >
> >> > I already published a pseudo-sprintf function in the wiki here:
> >> > http://wiki.postgresql.org/wiki/Sprintf I'm looking for something
> >> >
2009/9/9 Hannu Krosing :
> On Wed, 2009-09-09 at 21:57 +0200, Pavel Stehule wrote:
>> 2009/9/9 Alvaro Herrera :
>> > Pavel Stehule escribió:
>> >> 2009/9/9 Alvaro Herrera :
>> >
>> >> > I already published a pseudo-sprintf function in the wiki here:
>> >> > http://wiki.postgresql.org/wiki/Sprintf
Hannu Krosing writes:
> maybe we could (re/ab)use parametrized types and define
> anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
> the number in parentheses
Yeah, that idea occurred to me too. The immediate practical problem is
that we don't store a typmod for function
On Wed, 2009-09-09 at 15:10 -0400, Robert Haas wrote:
> On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Another possible example is sprintf:
> >
> >> create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
> >> returns text
> >
> >> In order for thi
On Wed, 2009-09-09 at 09:39 -0400, Tom Lane wrote:
> Peter Eisentraut 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
2009/9/9 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/9/9 Alvaro Herrera :
>
>> > I already published a pseudo-sprintf function in the wiki here:
>> > http://wiki.postgresql.org/wiki/Sprintf I'm looking for something
>> > better, not just the same hacks.
>> >
>> > I don't see any good reason
Pavel Stehule escribió:
> 2009/9/9 Alvaro Herrera :
> > I already published a pseudo-sprintf function in the wiki here:
> > http://wiki.postgresql.org/wiki/Sprintf I'm looking for something
> > better, not just the same hacks.
> >
> > I don't see any good reason that the function needs to be far
2009/9/9 Robert Haas :
> On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane wrote:
>> Alvaro Herrera 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_M
2009/9/9 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/9/9 Alvaro Herrera :
>> > Pavel Stehule escribió:
>> >
>> >> we are able to write sprintf(text, variadic "any") returns text, but only
>> >> in C
>> >
>> > Hmm, should we provide that function in core?
>>
>> We should it, but I prefer som
Robert Haas escribió:
> 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.
Function references would be neat -- I remember want
Robert Haas writes:
> What we need is a system where base types are represented
> by an OID, but derived types (list and functional types) are built up
> using type constructors that take other types as arguments.
This is SQL, not Haskell. What you suggest seems about two orders of
magnitude mor
On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane wrote:
> Alvaro Herrera 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, whic
Tom Lane wrote:
> Alvaro Herrera 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.
Hmm, it doesn't seem to be allowed?
alvherre=# creat
On Sep 8, 2009, at 10:48 AM, David Fetter wrote:
I'd like to see pseudo-types like ANYNUMERIC, and allow it to take an
array decorator, which would really help for math-ish functions. Not
sure where that fits in this discussion.
Perhaps typcategory could be leveraged here?
..Tho, if I unders
Pavel Stehule escribió:
> 2009/9/9 Alvaro Herrera :
> > Pavel Stehule escribió:
> >
> >> we are able to write sprintf(text, variadic "any") returns text, but only
> >> in C
> >
> > Hmm, should we provide that function in core?
>
> We should it, but I prefer some pgfoundry or contrib package. spri
On Sep 9, 2009, at 4:44 AM, Peter Eisentraut wrote:
That's beginning to sound a bit like a generics feature. E.g.,
CREATE FUNCTION the_same(arg_a T, arg_b T) RETURNS bool AS $$
SELECT arg_a IS DISTINCT FROM arg_b;
$$;
mmm, yeah... ISTM that expansion in this area should probably head
toward
1 - 100 of 139 matches
Mail list logo
