Cultural Sublimation wrote:
>> Unfortunately for you, they are not different types. If the OCaml
>> binding thinks they are, it's the binding's problem; especially since
>> the binding seems to be using a completely lame method of trying to tell
>> the difference.
>
> Hi,
>
> In OCaml and in oth
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Firstly, the output of most queries is of a type not represented
> anywhere in the catalogs. It's mostly going to be an undeclared record
> whose members are listed in pg_type. So using pg_attribute for anything
> like this is probably completely
On Thu, Sep 13, 2007 at 05:02:10AM -0700, Cultural Sublimation wrote:
> In OCaml and in other languages with strong type systems, "int4 never NULL"
> and "int4 possibly NULL" are definitely different types. I think the source
> of the problem here is that SQL has a different philosophy, one where
Hi,
> The thing behind the RETURNS in a function is always a data type,
> regardless if it is one that has been explicitly declared with
> CREATE TYPE or implicitly by CREATE TABLE.
>
> There are no NOT NULL conditions for data types.
>
> NOT NULL only exists for table columns.
Thanks for the i
> Unfortunately for you, they are not different types. If the OCaml
> binding thinks they are, it's the binding's problem; especially since
> the binding seems to be using a completely lame method of trying to tell
> the difference.
Hi,
In OCaml and in other languages with strong type systems, "
Cultural Sublimation wrote:
[has a problem because a SETOF RECORD function can return NULLs in
record attributes]
>The client software obtains the type
> information by querying Postgresql, namely by checking the attnotnull
> column in the pg_attribute catalog. Theref
Cultural Sublimation <[EMAIL PROTECTED]> writes:
>> Interesting. What language are you using?
> OCaml. The type-safety comes from the PG'OCaml bindings, which basically
> check if the types in the database are consistent with the types in the
> program.
Unfortunately for you, they are not diffe
> Interesting. What language are you using?
OCaml. The type-safety comes from the PG'OCaml bindings, which basically
check if the types in the database are consistent with the types in the
program. It's very neat technology, but unfortunately sometimes it seems
too advanced for its own good, si
Cultural Sublimation wrote:
> Hi,
>
> > I presume you mean that the server is saying the column can be NULL,
> > not that it is actually NULL, since:
>
> Yeah, that is the correct semantics: "it can be NULL". It does make
> a world of difference on the client side, because an "int4 never NULL"
Hi,
> I presume you mean that the server is saying the column can be NULL,
> not that it is actually NULL, since:
Yeah, that is the correct semantics: "it can be NULL". It does make
a world of difference on the client side, because an "int4 never NULL"
is a different type from "int4 possibly NU
Hi Tom,
> In any case, it appears to me that your gripe has little to do with
> whether there's actually any enforcement of the not-null condition,
> and much to do with whether some unspecified client-side software
> thinks the query result column is guaranteed not null. Most likely
> you're goi
On Wed, Sep 12, 2007 at 02:22:46PM -0700, Cultural Sublimation wrote:
> SELECT movie_id, movie_name FROM get_movies ();
> => returns a SETOF of (int4 NULL, text NULL)
I presume you mean that the server is saying the column can be NULL,
not that it is actually NULL, since:
> One note: I know this
Richard Broersma Jr wrote:
>
> --- Cultural Sublimation <[EMAIL PROTECTED]> wrote:
>
> > > I don't know if this will work, but here is another idea:
> > >
> > > SELECT movie_id, movie_name
> > > FROM get_movies() AS ( int4 NOT NULL, text NOT NULL );
> > >
> >
> > Hi,
> >
> > Nope. That's n
Cultural Sublimation <[EMAIL PROTECTED]> writes:
> This bug seems to obvious to have been generally missed.
It's not a bug: there is no mechanism enforcing that the result of a
function can't be NULL.
For functions returning scalars you can get the effect by declaring the
result as being of a dom
--- Cultural Sublimation <[EMAIL PROTECTED]> wrote:
> > I don't know if this will work, but here is another idea:
> >
> > SELECT movie_id, movie_name
> > FROM get_movies() AS ( int4 NOT NULL, text NOT NULL );
> >
>
> Hi,
>
> Nope. That's not even valid syntax...
It isn't valid SQL spec sy
> I don't know if this will work, but here is another idea:
>
> SELECT movie_id, movie_name
> FROM get_movies() AS ( int4 NOT NULL, text NOT NULL );
>
Hi,
Nope. That's not even valid syntax...
But thanks for effort, anyway!
Cheers,
C.S.
___
--- Cultural Sublimation <[EMAIL PROTECTED]> wrote:
> > CREATE FUNCTION get_movies ()
> > RETURNS SETOF get_movies_t
> > LANGUAGE sql STABLE
> > AS
> > $$
> > SELECT movie_id, movie_name FROM movies
> > WHERE movie_id NOT NULL AND movie_name NOT NULL;
> > $$
>
>
> SELECT movie_id, movie_name FR
>
> I haven't tried it with a view yet - so this may or may not work. But try
> giving it a shot by declaring a view
>
> create view vmovies as
> select movie_id,movie_text from movies
>
> and let your function return setof vmovies
>
> Maybe that works - I think it should.
Hey,
Thanks for th
> CREATE FUNCTION get_movies ()
> RETURNS SETOF get_movies_t
> LANGUAGE sql STABLE
> AS
> $$
> SELECT movie_id, movie_name FROM movies
> WHERE movie_id NOT NULL AND movie_name NOT NULL;
> $$
Hey,
Thanks for the suggestion. Unfortunately, it still doesn't work.
Here is what Postgresql is tellin
Cultural Sublimation escreveu:
Hi,
I am not sure if this qualifies as a bug report or a feature request,
but I don't see any way to tell Postgresql that the members of a record
cannot be NULL. This causes all kinds of problems when this record
is used to declare the return type of a function.
I haven't tried it with a view yet - so this may or may not work. But try
giving it a shot by declaring a view
create view vmovies as
select movie_id,movie_text from movies
and let your function return setof vmovies
Maybe that works - I think it should.
Uwe
On Wednesday 12 September 2007, C
Hi again,
> However, your answer did give me an idea: instead of declaring
> "get_movies_t" as a record, I declare it as dummy table, and return
> that (see code at the end).
> This works, though it is *very* ugly. Any other ideas?
My apologies, but it turns out that this solution doesn't work
> Why do you create an extra type for that?
> Just have your method return "movies"
Hi,
Thanks for the answer. The simple example obfuscates the fact that in reality
the table has a few extra columns that are omitted from get_movies_t.
Therefore, I cannot return "movies".
However, your answer
Why do you create an extra type for that?
Just have your method return "movies"
i.e.
CREATE FUNCTION get_movies ()
RETURNS SETOF movies
...
...
HTH
Uwe
On Wednesday 12 September 2007, Cultural Sublimation wrote:
> Hi,
>
> I am not sure if this qualifies as a bug report or a feature request,
>
On 9/12/07, Cultural Sublimation <[EMAIL PROTECTED]> wrote:
> Thanks for the help!
Not really following you, but try these:
CREATE OR REPLACE FUNCTION GET_MOVIES ()
RETURNS SETOF MOVIES
LANGUAGE SQL STABLE
AS
$$
SELECT MOVIE_ID, MOVIE_NAME FROM MOVIES;
$$;
-- OR --
CREATE OR REPLACE FUNCTION GE
Hi,
I am not sure if this qualifies as a bug report or a feature request,
but I don't see any way to tell Postgresql that the members of a record
cannot be NULL. This causes all kinds of problems when this record
is used to declare the return type of a function. Suppose I had the
following table
26 matches
Mail list logo
