Custom methods for HSTORE and ANY ( method ) in psql

[dinesh-it]

Please review and incorporate HSTORE and ANY methods used for psql.

[ribasushi]

Hi, and sorry for the late reply!

First of all thank you very much for your contribution. As you noticed the original thread where you saw the implementation is quite old, and the feature has not yet been included in SQL::Abstract proper. This is due to architectural considerations: the 1.x series SQL::Abstract has no clean way of supporting dialects, and as such we are trying to only include "lowest common denominator" features in the main package. The pg-specific dialects fall outside of this category.

If you are interested in using this functionality with DBIx::Class specifically - let me know and I can tell you more about what is necessary to get this piece of code into the appropriate library (some things off the top of my head - there will definitely be need for tests, and handling of literals/-ident needs to be clarified).

Cheers!

[dinesh-it]

Thanks for your reply, and yes I am trying to use it with DBIx::Class. Can you please tell me the appropriate library where I can add this code.

Thank you.

[timbunce]

Ping @ribasushi. I've a co-worker interested in this topic.

[ribasushi]

Hi @dinesh-it, @timbunce,

Sorry for dropping the ball on this, github did not notify me (yet again) of activity post-close. This PR was dealing with two things - ANY and HSTORE, which I will address separately.

For ANY there is no need to add anything - it is covered by the current "generic operator" support:

rabbit@Ahasver:~$ perl -MSQL::Abstract -MDevel::Dwarn -e 'Dwarn [ SQL::Abstract->new->where({ Group => { -any => { -ident => "Prepay" } } }) ]'
[
  " WHERE ( Group ANY Prepay )"
]
rabbit@Ahasver:~$ perl -MSQL::Abstract -MDevel::Dwarn -e 'Dwarn [ SQL::Abstract->new->where({ Group => { -any => "Prepay" } }) ]'
[
  " WHERE ( Group ANY ? )",
  "Prepay"
]

For HSTORE implementing -> alone and giving it an arbitrary name of inhstore seems a bit shortsighted to me from an API-design standpoint. I think any future work needs to strive to cover the entire gamut of currently supported operators with an option open to future expansion.

Furthermore given how this is at this point firmly Postgres-only syntax (following their decision to repurpose ?), its best implementation venue would be a subclass of DBIx::Class::SQLMaker settable post-connect, or something like that.

These are just superficial thoughts off-the-cuff. I have never used HSTORE personally, hence do not have much to add in terms of design advice.

[timbunce]

Thanks @ribasushi. All makes sense.
(Minor aside: I suspect JSON/JSONB type usage, and thus operators, will become much more common than HSTORE over the next few years.)

[ilmari]

@ribasushi: The generic operator support is not quite enough for ANY, since the syntax is foo = ANY(?) (see http://www.postgresql.org/docs/current/static/functions-comparisons.html#AEN19686):

$ reply
0> my $s = SQL::Abstract->new
[…]
1> $s->where({foo => { -any => { -value => [2] } }})
$res[1] = [
  ' WHERE ( foo ANY ? )',
  [
    2
  ]
]

2> $s->where({foo => { '=' => { -any => { -value => [2] }}}})
$res[2] = [
  ' WHERE ( foo = (ANY ?) )',
  [
    2
  ]
]

[ribasushi]

@ilmari Ah Pg is bracket-sensitive isn't it. Then the comment about HSTORE applies here too - I believe it is of utmost importance to keep SQL::Abstract well... abstract. And keep any additional non-standard (standard in the practical sense of the word) behaviors to subclasses.