Prev: New feature request: FlashBack Query
Next: Implicit casts with generic arrays
From: Tom Lane on 19 Feb 2007 10:50
Peter Eisentraut <peter_e(a)gmx.net> writes:
> Am Montag, 19. Februar 2007 16:26 schrieb Tom Lane:
>> Peter Eisentraut <peter_e(a)gmx.net> writes:
>>> Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
>>>> This breaks the fmgrtab generator on msvc.
>>
>>> It's intentional.
>>
>> Kindly change that intention.

> What is wrong?

Well, in the first place Gen_fmgrtab.sh is producing garbage:

#define F_CURSOR_TO_XML DATAINSERT
#define F_CURSOR_TO_XMLSCHEMA DATAINSERT
#define F_QUERY_TO_XML DATAINSERT
#define F_QUERY_TO_XML_AND_XMLSCHEMA DATAINSERT
#define F_QUERY_TO_XMLSCHEMA DATAINSERT
#define F_TABLE_TO_XML DATAINSERT
#define F_TABLE_TO_XML_AND_XMLSCHEMA DATAINSERT
#define F_TABLE_TO_XMLSCHEMA DATAINSERT
#define F_BYTEAOUT 31
#define F_CHAROUT 33

const FmgrBuiltin fmgr_builtins[] = {
{ 0, "cursor_to_xml", 5, true, false, cursor_to_xml },
{ 0, "cursor_to_xmlschema", 4, true, false, cursor_to_xmlschema },
{ 0, "query_to_xml", 4, true, false, query_to_xml },
{ 0, "query_to_xml_and_xmlschema", 4, true, false, query_to_xml_and_xmlschema },
{ 0, "query_to_xmlschema", 4, true, false, query_to_xmlschema },
{ 0, "table_to_xml", 4, true, false, table_to_xml },
{ 0, "table_to_xml_and_xmlschema", 4, true, false, table_to_xml_and_xmlschema },
{ 0, "table_to_xmlschema", 4, true, false, table_to_xmlschema },
{ 31, "byteaout", 1, true, false, byteaout },

The fact that that table is broken means you're incurring expensive
linear searches to invoke these functions. It's only by chance that
it works at all...

In the second place, if you don't want to predetermine OIDs for your
functions then they shouldn't be in hardwired pg_proc.h rows at all.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

From: Gregory Stark on 19 Feb 2007 11:08
"Tom Lane" <tgl(a)sss.pgh.pa.us> writes:

> In the second place, if you don't want to predetermine OIDs for your
> functions then they shouldn't be in hardwired pg_proc.h rows at all.

Is there any place to hook in to create things like procedures or other SQL
objects that don't really need hard coded OIDs?

It seems like we could make the catalogs much easier to maintain by ripping
out everything that isn't needed by the system tables themselves and having
initdb create them by running a plain SQL script.

In particular I'm looking towards having all the operators and associated
hardware except for the basic btree operators for types used by the system
tables be created in plain SQL.

It might also reduce the pain OID conflicts cause.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

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

http://www.postgresql.org/docs/faq

From: Peter Eisentraut on 19 Feb 2007 11:10
Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
> Well, in the first place Gen_fmgrtab.sh is producing garbage:

Uh, ok, that needs fixing.

> In the second place, if you don't want to predetermine OIDs for your
> functions then they shouldn't be in hardwired pg_proc.h rows at all.

Where else would you put them?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

From: Tom Lane on 19 Feb 2007 11:18
Peter Eisentraut <peter_e(a)gmx.net> writes:
> Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
>> In the second place, if you don't want to predetermine OIDs for your
>> functions then they shouldn't be in hardwired pg_proc.h rows at all.

> Where else would you put them?

SQL script maybe, much along the lines Greg was just mentioning.
(I'd been thinking myself earlier that pg_amop/amproc/etc would be a
whole lot easier to maintain if we could feed CREATE OPERATOR CLASS
commands to the bootstrap process.) But getting there will take
nontrivial work; you can't just decide to leave out a few OIDs on the
spur of the moment.

Magnus, I'd suggest reverting whatever you did to your MSVC script,
so we'll find out the next time someone makes this mistake...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

From: Alvaro Herrera on 19 Feb 2007 11:34
Peter Eisentraut wrote:
> Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
> > Well, in the first place Gen_fmgrtab.sh is producing garbage:
>
> Uh, ok, that needs fixing.
>
> > In the second place, if you don't want to predetermine OIDs for your
> > functions then they shouldn't be in hardwired pg_proc.h rows at all.
>
> Where else would you put them?

But _why_ wouldn't you want to have fixed OIDs for the functions? I'm
not seeing the benefit.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

http://www.postgresql.org/docs/faq

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: New feature request: FlashBack Query
Next: Implicit casts with generic arrays