Table definition about holycorn HOT 4 CLOSED

closing. Think this would incur too much overhead as initialize(OPTIONS) is called for every query. Most (all?) of the time the ruby will not want to dynamically change.

OPTIONS can be used to pass extra parameters as needed.

from holycorn.

This is actually a very good question, and I've been asked many times so here's an "official" answer 😄

PG provides IMPORT FOREIGN SCHEMA that is essentially a way for it to "ask" foreign servers for their table definitions.

Most holycorn-pro users felt the need to get it, and also wanted to encapsulate more information in user mappings. I got both IMPORT FOREIGN SCHEMA and USER MAPPINGs supported there.

Any cool usage of holycorn on your side? 😉

from holycorn.

Thanks Frank.

I keep running into yaml in a text column and wanting a way to parse in Postgres. So something like pl/ruby (or lua or js - but ruby would be the best) to allow queries to extract a column, change it or join.

Your video on the three possible options was great. I do wonder what pl/mruby would be like. But the fdw bridge seems to buy a lot in its own right.

Didn't get the chance to even get holycorn up and running yet. Little intimidated.
Also, not sure it would help us without where or joins.

Thanks for the great video, project, and I'll share what I find.

from holycorn.

Long overdue but finally decided to open source IMPORT FOREIGN SCHEMA (code) (hacktoberfest is great ahah).

Anyways, you can do something like this now:

IMPORT FOREIGN SCHEMA holycorn_schema
FROM SERVER holycorn_server
INTO holycorn_tables
OPTIONS ( wrapper_class '...'
        , foo 'bar'
        , baz 'bat'
        );

and you'll end up with foo and baz passed within a hash to the #import_schema method of your wrapper class.

If you were dynamically generating mappings before, then you could pass some information from that SQL statement to the wrapper, and decide what to do in Ruby-land code.

Hope this helps.

from holycorn.