On Nov 01 09:28, Andrew Sullivan wrote:
> On Tue, Oct 31, 2006 at 11:45:00PM +0200, Volkan YAZICI wrote:
> > > Note the column headers. They're differently shaped. Because
> > > pseudotype record doesn't have a shape, equality doesn't make sense,
> > > so you need two shapes that are already identical, so they can use
> > > the matching rules for that.
> >
> > Can you be more verbose please? I couldn't understand what you mean with
> > "shape".
First, thanks for your answer.
> It's an analogy, really. The datatype numeric() for instance, is
> determined. Because it's determined, you can have determinate rules
> for comparing one to another.
>
> But the pseudotype record doesn't work that way. It can accept
> whatever you put in there
But there should be a way to reach the types of the attributes of the
record data type. Otherwise, how would it be possible to place it into
another tuple as an attribute. And AFAIK, there're some (hardcoded) ways
to get TupleDesc of a record data type. From this point of view, as long
as you're able to get the TupleDesc of a record data type, you should
have been able to compare it with any other row/record data type.
OTOH, let's assume that we have no idea about attributes of a record
data type. So how does PostgreSQL manage to output it without knowing
attributes' typoutput functions due to their data type OIDs? That sounds
like a contradiction to me.
> which is why you can define a variable as type record, and then select
> from different tables (or even different datatypes!) to it in plpgsql:
> it accommodates these different things.
IMHO, plpgsql's record data type is a totally different thing.
> The trade-off is that comparing a record to another record won't
> always work: because what a record is is not pre-determined, you
> can't have determinate rules for comparing one record to another.
> And without determinate rules, you can't have an equality operator.
IIRC, there's some kind of type registration mechanism in the PostgreSQL
internals while forming a record data type. (I'm not sure but, IIRC,
BlessTupleDesc() registers the TupleDesc into somewhere, so it'll be
able to reach its attributes through its registered TupleDesc in the
future.)
Can you point me to related source/README files in the PostgreSQL
source? I read a little bit about it in the backend/parser/*.c and
couldn't see the distinction you explained. Maybe I was looking at wrong
lines.
Regards.