Skip site navigation (1) Skip section navigation (2)

Re: selecting from cursor

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: selecting from cursor
Date: 2001-07-03 18:00:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 3 Jul 2001, Tom Lane wrote:

> Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> > On Tue, 3 Jul 2001, Tom Lane wrote:
> >> So you have four (soon to be six or seven) different structs that *must*
> >> have the same fields?  I don't think that's cleaner than a union ...
> > Please see my diffs. Its implemented via #define to declare all common
> > fields. 
> > #define RTE_COMMON_FIELDS \
> >     NodeTag     type; \
> >     [etc]
> I don't think that technique is cleaner than a union, either ;-).
> The macro definition is a pain in the neck: you have to play games with
> semicolon placement, most tools won't autoindent it nicely, etc etc.

True true. On other hand, unlike union, its automatically typechecked, you
cannot by mistake reference a field you shouldn't be referencing.

Strict typechecking allows one to explicitly declare which type your
function takes if you want, and force errors if you miscast something. I
think discipline is a good thing here...

But really its your call, no point in arguing :)

> But the main point is that I think NodeType = RangeTblEntry with
> a separate subtype field is a better way to go than making a bunch of
> different NodeType values.  When most of the fields are common, as in
> this case, it's going to be true that many places only want to know
> "is it a rangetable entry or not?"

That's why I have IsA_RTE(node) macro. (Same as we have IsA_Join and
IsA_JoinPath already). It 

In response to


pgsql-hackers by date

Next:From: Bill StudenmundDate: 2001-07-03 18:16:21
Subject: Re: [OT] Any major users of postgresql?
Previous:From: Joe BrennerDate: 2001-07-03 17:44:04
Subject: [OT] Any major users of postgresql?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group