[HACKERS] Now it's my turn...

[Vadim Mikheev]

Baby girl on Jun 27.

Vadim



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Now it's my turn...

[Tom Lane]

Vadim Mikheev [EMAIL PROTECTED] writes:
 Baby girl on Jun 27.

Congratulations!

I suppose now you'll have no time for hacking PG for awhile ...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Now it's my turn...

[Ing. Roberto Andrade Fonseca]

Hi:

On Fri, 29 Jun 2001, Vadim Mikheev wrote:

 Baby girl on Jun 27.
 
Congratulations to Vadim, his wife and his daughter!!!

Saludos,

Roberto Andrade Fonseca
[EMAIL PROTECTED]


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

[HACKERS] Another regression test fails to stand the test of time

[Tom Lane]

abstime regression test started failing this morning.

SELECT '' AS six, ABSTIME_TBL.*
   WHERE ABSTIME_TBL.f1  abstime 'Jun 30, 2001';

This used to select 'current', but doesn't anymore.  Ooops.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] RangeTblEntry modifications

[Tom Lane]

Alex Pilosov [EMAIL PROTECTED] writes:
 2) Keep one type, but unionize the fields. RTE definition would be:
 I'm not sure which method is less ugly. I'm leaning towards 2).

I like that better, also, mainly because it would force code updates
everyplace that the RTE-type-specific fields are accessed; less chance
of incorrect code getting overlooked that way.

Note that some of the comments would be obsolete, eg

 /* Fields valid for a plain relation RTE (else NULL/zero): */

They're not null/0 for a non-relation RTE, they're just not defined at
all.

 struct {
 /* Fields valid for function-as portal RTE */
 char   *portal;
 TupleDesc  tupleDesc;
 } func;

I'm not sure I buy this, however.  You'll need an actual
RTE-as-function-call variant that has the function OID and compiled list
of arguments.  Remember that the parsetree may live a lot longer than
any specific Portal.  For a function call, we'll need to build the
Portal from the function-call-describing RTE at the start of execution,
not during parsing.

This point may also make select from cursor rather harder than it
appears at first glance.  You may want to back off on that part for now.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]