Re: Is it possible to return custom type as proper ROW?

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com>
Subject: Re: Is it possible to return custom type as proper ROW?
Date: 2006-10-11 21:02:08
Message-ID: 1160600528.31966.35.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2006-10-11 at 11:05 -0700, Uwe C. Schroeder wrote:
> On Wednesday 11 October 2006 10:42, A. Kretschmer wrote:
> > am Wed, dem 11.10.2006, um 12:56:51 -0400 mailte Tom Lane folgendes:
> > > Andreas Kretschmer <akretschmer(at)spamfence(dot)net> writes:
> > > > Joe Kramer <cckramer(at)gmail(dot)com> schrieb:
> > > >> I want to get:
> > > >> item_id | last_update
> > > >> -------------------------------------
> > > >> 32 | 1234-12-12 12:12:12
> > > >
> > > > Untested:
> > > > SELECT item_id, last_update from public.new_item(3,2);
> > >
> > > Or just
> > > SELECT * FROM public.new_item(3,2);
> >
> > Yes, but i have learned, that 'SELECT * ...' is evil...
>
> Well, "SELECT *" is only evil if your application relies on a specific column
> order to function. The moment you change the table layout and you're using
> "select *" your application will cease functioning.
> My app uses tons of select *, but then I wrote an object mapper that queries
> the information schema at startup - so it's aware of table changes and
> adjusts accordingly.
>

It's aware of the tables as they exist at startup. That may change
between when the mapper looks at the information schema and when it gets
the results of a query.

If you know what it's doing it's probably fine, but that doesn't seem
like a general solution.

Regards,
Jeff Davis

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Vivek Khera 2006-10-11 21:03:36 Re: [Slony1-general] Using slony with many schema's
Previous Message Jonathan Vanasco 2006-10-11 20:53:53 question on renaming a foreign key