Dario Teixeira writes:
> I doubt there is a clean way around this (barring Postgresql implementing
> option types). Therefore, I'm working on a workaround that involves the
> Postgresql side annotating the nullability of type definitions by issuing
> comments on the type (using COMMENT ON). Yes,
Hi,
> Why do you think that's a useful activity for client-side
> code to engage in?
Strongly typed languages like Ocaml and Haskell deal with the possibility
of missing values by having "option types". Though at first glance SQL's
NULL seems like a similar concept, in fact NULL is more like a
darioteixe...@yahoo.com writes:
> Thanks for the info. So, given that RowDescription is a dead-end, is there
> any other way I can determine the composite type associated with a function
> return?
Why do you think that's a useful activity for client-side code to engage
in?
Hi,
> It's intentional; IIRC, the current behavior is defined that way because
> that's what the JDBC driver needs to implement the JDBC specs. Putting
> information about composite types where information about tables is
> expected would confuse the heck out of existing client code.
Thanks for
Hi,
> It is not as elegant as you would like, but maybe one idea
> is to create your own alias of the built in type so you can
> determine the answer just by looking at the column type. For
> example, instead of using "int" in CREATE TYPE above, create
> a your own type equivalent to an integer.
Dario Teixeira writes:
> *However*, if I create a new type (which has an associated pg_class entry),
> and define a function which returns a SETOF that type, RowDescription will
> not tell me its OID. For example:
> ...
> Is this a bug or a conscious decision?
It's intentional; IIRC, the current
On Jun 22, 2009, at 4:57 PM, Dario Teixeira wrote:
*However*, if I create a new type (which has an associated pg_class
entry),
and define a function which returns a SETOF that type,
RowDescription will
not tell me its OID. For example:
CREATE TYPE foobar_t AS (quant int);
CREATE FUNCTION
Hi,
> The information you want is always returned from the query
> as a row description message. This includes the type oid of
> real and computed columns.
>
> See the RowDescription message on this page for details:
Thanks for the reply. Note that is in fact RowDescription that PG'OCaml
is al
On Jun 22, 2009, at 11:43 AM, Dario Teixeira wrote:
How are you talking to the database ? ODBC? JDBC? LibPQ? Something
else?
Or do you want this from within PL/PgSQL ?
I'm hacking on a client-side library which talks directly to the
Postmaster
using the wire protocol [1]. I need this info
Hi,
> How are you talking to the database ? ODBC? JDBC? LibPQ? Something else?
> Or do you want this from within PL/PgSQL ?
I'm hacking on a client-side library which talks directly to the Postmaster
using the wire protocol [1]. I need this information to improve some of the
nullability-detectio
2009/6/22 Dario Teixeira :
>
> Hi,
>
> Is there some way to find out meta-information about the columns generated
> by any SELECT query? If the SELECT returns values from a regular table or
> a view, I can use pg_class and pg_attribute to get the info I need:
>
> CREATE TABLE foobar (quant int);
>
On Mon, 2009-06-22 at 05:26 -0700, Dario Teixeira wrote:
> Is there some way to find out meta-information about the columns generated
> by any SELECT query?
How are you talking to the database ? ODBC? JDBC? LibPQ? Something else?
Or do you want this from within PL/PgSQL ?
You'll usually find tha
Hi,
Is there some way to find out meta-information about the columns generated
by any SELECT query? If the SELECT returns values from a regular table or
a view, I can use pg_class and pg_attribute to get the info I need:
CREATE TABLE foobar (quant int);
SELECT quant FROM foobar;
SELECT attname,
13 matches
Mail list logo
