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
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 variables. Result
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:
In my proposal I
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
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 is
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
RESULTSET.
How
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 using some
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 specific
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 specific
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 to system
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
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 had?
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
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 meaning of
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 me like
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
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 good
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
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 TYPE
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 composite
20 matches
Mail list logo
