Hello
After some days I thing, so idea of local types is wrong. Maybe we can
register output types for or SRF functions (maybe only for table
functions), but this mechanism is redundant to explicit custom types.
Local functions types are nice, they allows better compile time check,
but they are un
2008/5/22 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-05-21 at 23:06 +0200, Pavel Stehule wrote:
>> 2008/5/21 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
>> >> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>> >>
On Wed, 2008-05-21 at 23:06 +0200, Pavel Stehule wrote:
> 2008/5/21 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
> >> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> >> >> In my proposal I don't create any default variab
2008/5/21 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
>> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>> >> In my proposal I don't create any default variables. Result type is
>> >> only virtual - I don't need write it t
2008/5/21 Merlin Moncure <[EMAIL PROTECTED]>:
> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>>> In my proposal I don't create any default variables. Result type is
>>> only virtual - I don't need write it to system directory. I thing it's
>>> better than using some spe
2008/5/21 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-05-21 at 18:12 +0200, Pavel Stehule wrote:
>> Hello
>
> ...
>
>> In my proposal I don't create any default variables. Result type is
>> only virtual - I don't need write it to system directory. I thing it's
>> better than using some specif
On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> >> In my proposal I don't create any default variables. Result type is
> >> only virtual - I don't need write it to system directory. I thing it's
> >> better than
On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>> In my proposal I don't create any default variables. Result type is
>> only virtual - I don't need write it to system directory. I thing it's
>> better than using some specific predeclared type as RESULTTYPE OR
>> RESULTSE
On Wed, 2008-05-21 at 18:12 +0200, Pavel Stehule wrote:
> Hello
...
> In my proposal I don't create any default variables. Result type is
> only virtual - I don't need write it to system directory. I thing it's
> better than using some specific predeclared type as RESULTTYPE OR
> RESULTSET.
How
Hello
I am returning back to my patch and older proposal
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php .
Some work did Neil Conway
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00501.php and
he commited half of this patch - RETURN QUERY part.
Problematic part of my
>> I thought you said this was just syntactic sugar for capabilities we
>> already had?
> My mistake. I am sorry. I have to store somewhere flag. One bit, which
> signalise "don't use OUT arguments as function's parameters".
Huh? What exactly is the meaning of the arguments then?
It sounds to
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I thought you said this was just syntactic sugar for capabilities we
>> already had?
> My mistake. I am sorry. I have to store somewhere flag. One bit, which
> signalise "don't use OUT arguments as function's parameters".
Huh? What exactly is the m
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> it can by more simple than I though. I need only one flag, and if its
true
> then I don't create language variables for OUT params. But I need one
next
> column in pg_proc.
I thought you said this was just syntactic sugar for capabilities we
alrea
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> it can by more simple than I though. I need only one flag, and if its true
> then I don't create language variables for OUT params. But I need one next
> column in pg_proc.
I thought you said this was just syntactic sugar for capabilities we
already
Hello,
it can by more simple than I though. I need only one flag, and if its true
then I don't create language variables for OUT params. But I need one next
column in pg_proc.
Currently a lot of columns in pg_proc is bool. What about one binary columns
for other options? I hope so next versi
On Tue, 2007-02-06 at 23:43 +0100, Pavel Stehule wrote:
> ANSI SQL 2003 goes with new type of functions - table functions. With this
> syntax
...
> All necessary infrastructure is done. Implementation needs propably only
> small changes in parser.
...
> * conformance with ansi sql 2003
Sounds g
> Hello,
>
> Currently PostgreSQL support set returning functions.
>
> ANSI SQL 2003 goes with new type of functions - table functions. With
this
> syntax
>
> CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
>
> PostgreSQL equal statements are:
>
> CREATE TYPE tmptype AS (c1 t1, ...)
> CREATE
Pavel Stehule wrote:
> Hello,
>
> Currently PostgreSQL support set returning functions.
>
> ANSI SQL 2003 goes with new type of functions - table functions. With
> this syntax
>
> CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
>
Yeah this should be pretty easy because a table is just a comp
On Tue, 6 Feb 2007, Pavel Stehule wrote:
> Hello,
>
> Currently PostgreSQL support set returning functions.
>
> ANSI SQL 2003 goes with new type of functions - table functions. With this
> syntax
>
> CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
>
> PostgreSQL equal statements are:
>
> CREATE
Hello,
Currently PostgreSQL support set returning functions.
ANSI SQL 2003 goes with new type of functions - table functions. With this
syntax
CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
PostgreSQL equal statements are:
CREATE TYPE tmptype AS (c1 t1, ...)
CREATE FUNCTION ... RETURNS S
20 matches
Mail list logo