Hello everyone,
I've been trying to get the postgreSQL tsvector type work with SQLAlchemy
without dropping into raw SQL. I was mostly interested in queries and the DDL
to create the initial table.
Through some trial and error, I have a setup working which I've detailed
here
the TsVector type looks perfect!
if you were to package that up for inclusion, it would likely subclass
TypeEngine and you’d implement PGTypeCompiler.visit_TSVECTOR.we appear to
have a little bit of “tsvector” code already (we implement the “match” operator
as %s @@ to_tsquery(%s)” ) but
Michael Bayer mike_mp at zzzcomputing.com writes:
the TsVector type looks perfect!
if you were to package that up for inclusion, it would likely subclass
TypeEngine and you’d implement
PGTypeCompiler.visit_TSVECTOR.we appear to have a little bit of
“tsvector” code already (we
I have a self join (same one I've been asking about recently) and turns
out that there should be a one to one mapping for the aggregated rows on
one side to the aggregated rows on the other side.
If that's not true, then the returned rows are rubbish. In all my
current use cases it *should*
well the alternative to full outer join is a union of two outer joins - more
tedious.“full outer join” isn’t in the library but you can just subclass
Join and do a @compiles to get that exact syntax.
On Dec 2, 2013, at 2:05 PM, Chris Withers ch...@simplistix.co.uk wrote:
I have a self
On Monday, December 2, 2013 2:46:20 PM UTC-5, Michael Bayer wrote:
well the alternative to full outer join is a union of two outer joins -
more tedious.“full outer join” isn’t in the library but you can just
subclass Join and do a @compiles to get that exact syntax.
you could also
if someone wants to pullreq the kw argument “full=True” on .outerjoin(), if
it’s done effectively I won’t reject it.
On Dec 2, 2013, at 5:43 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
On Monday, December 2, 2013 2:46:20 PM UTC-5, Michael Bayer wrote:
well the alternative to full
