Re: Command Triggers - Mailing list pgsql-hackers

On Mon, Dec 19, 2011 at 11:20 AM, Andres Freund <andres@anarazel.de> wrote:
>> I do.  Anyone coding in PL/pgsql is going to find the nodeToString()
>> output unusable, and we can easily provide a built-in JSON datatype
>> with enough richness to make that problem go away in time for 9.2.
>> People in PL/python and PL/perl may be a bit better off, but I see no
>> reason to ship something for 9.2 and then break it for 9.3 when we
>> could perfectly well make that compatibility break before the release.
>>  (And, in case it's not clear, yes, I am volunteering to do the work,
>> if it comes down to that.)
> I personally think youre underestimating the complexity of providing a
> sensible json compatibility shim ontop the nodestring representation. But I
> would like to be proven wrong ;)
> Whats your idea?

I haven't gotten that far down into the minutiae yet.  :-)

But the reason I think it won't be too bad is because the current
representation is darn close to JSON already:

{VAR :varno 2 :varattno 1 :vartype 25 :vartypmod -1 :varcollid 100
:varlevelsup 0 :varnoold 2 :varoattno 1 :location 9998}

=>


{"_":"VAR","varno":2,"varattno":1,"vartype":25,"vartypmod":-1,"varcollid":100,"varlevelsup":0,"varnoold":2,"varoattno":1,"location":9998}


If you've got something like:

{OPEXPR :opno 98 :opfuncid 67 :opresulttype 16 :opretset false
:opcollid 0 :inputcollid 100 :args ({VAR :varno 2 :varattno 1 :vartype
25 :vartypmod -1 :varcollid 100 :varlevelsup 0 :varnoold 2 :varoattno
1 :location 9998} {VAR :varno 1 :varattno 1 :vartype 25 :vartypmod -1
:varcollid 100 :varlevelsup 0 :varnoold 1 :varoattno 1 :location
10009}) :location 10007}

...then the value for the "args" label will just be an object rather
than an integer.

>> But before we get bogged down in the data representation, I think we
>> need to make a more fundamental decision: to what extent are we OK
>> with exporting the parse tree at all, in any form?  Tom is arguing
>> that we shouldn't, and I see his point: the recent DROP command rework
>> would have broken everybody's command triggers if we had adopted this
>> proposal, and that would be a real shame, because I don't particularly
>> like the idea that we can't continue to improve the code and refactor
>> things because someone out there might be depending on an older and
>> less well-considered behavior.
> I don't see any realistic way to present the data in way thats abstracted from
> the internals for now. The infrastructure is completely new and we don't
> really know what it will be used for.

That's my feeling as well, but I'm hoping Tom or someone else has a better idea.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company