On Tue, Apr 17, 2012 at 2:49 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote: >> 1. We probably don't want the SQL syntax to be added to the grammar. >> This should be written as an extension, using custom functions as >> the API, instead of extra SQL syntax. > > Err, I missed that, and don't particularly agree with it.. Is there a > serious issue with the grammar defined in the SQL standard? The other > DBs which provide this- do they use the SQL grammar or something else? > > I'm not sure that I particularly *like* the SQL grammar, but if we're > going to implement this, we should really do it 'right'.
I think the danger is that fiddling with the grammar can be a ratsnest of learning how to deal with bison grammars and learning how to interpret the ANSI standard and bikeshedding. These are all parts of the open source world so maybe an argument could be made they should be part of a GSOC project but I fear they would swallow the whole project. But I think I agree that doing it as an external module would be strange and not very useful. I picture it instead as a new scan type which is basically a copy of heapscan or tidscan and uses various algorithms to decide which tuples to return. For a first cut pof I would leave out the grammar and just have a guc that enabled replacing the heap scan with a sample scan everywhere. But that would have to be done as a patch to Postgres to add the new scan type. It wouldn't make it much easier to have a hook that replaced one scan type with another I don't think. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
