On Sat, Apr 28, 2018 at 12:01 PM Pavel Stehule
wrote:
> Hi
>
> 2018-04-28 18:52 GMT+02:00 Jeremy Finzel :
>
>> It appears that neither pg_get_function_arguments
>> nor pg_get_function_identity_arguments could be used for this. I want to
>> get function argument data types from the catalog by ord
legrand legrand writes:
> So the only solution is to had queryId to ErrorData in this hook
> or create a new hook fired on ERROR and containing queryId ?
I see no particular need for a new hook. What's needed here is for
pgss_ExecutorRun (and maybe some other existing functions in
pg_stat_statem
OK I see ...
This hook should be used only for ERROR (no WARNING nor NOTICE ...)
and the only real interesting information is
ErrorData -> internalquery; /* text of internally-generated query */
This doesn't permit to (re)build the link to queryid
(that is based on parse tree, but not availa
On April 28, 2018 11:18:02 am PDT, "Peter J. Holzer" wrote:
On 2018-04-28 09:54:27 -0500, Steven Lembark wrote:
On Sat, 28 Apr 2018 08:02:21 +0200
"Peter J. Holzer" wrote:
> On 2018-04-27 22:52:39 +, g...@luxsci.net wrote:
> > Perhaps I'm extreme. In my ideal world, developers might n
On 2018-04-28 09:54:27 -0500, Steven Lembark wrote:
> On Sat, 28 Apr 2018 08:02:21 +0200
> "Peter J. Holzer" wrote:
>
> > On 2018-04-27 22:52:39 +, g...@luxsci.net wrote:
> > > Perhaps I'm extreme. In my ideal world, developers might not even
> > > know table names! I'm kidding ,sorta...
>
Hi list
I have recently upgraded my PostGIS 2.4.1 to 2.4.3, which introduced a
problem caused by one of the dependencies (geos 3.5.0 -> 3.6.2).
Now I would like to do a yum history undo to return my system to its
previous state, but when invoking yum history undo on that particular
transactio
Jeremy Finzel writes:
> It appears that neither pg_get_function_arguments
> nor pg_get_function_identity_arguments could be used for this. I want to
> get function argument data types from the catalog by ordinal position,
> without the argument name.
Something involving pg_proc.proargtypes::regt
Hi
2018-04-28 18:52 GMT+02:00 Jeremy Finzel :
> It appears that neither pg_get_function_arguments
> nor pg_get_function_identity_arguments could be used for this. I want to
> get function argument data types from the catalog by ordinal position,
> without the argument name.
>
> For example, I wa
It appears that neither pg_get_function_arguments
nor pg_get_function_identity_arguments could be used for this. I want to
get function argument data types from the catalog by ordinal position,
without the argument name.
For example, I want the same information for these 2 functions:
foo(p_1 int
> That seems un-pragmatic to me. IMHO if any business logic needs
> access to lots of data, it's best implemented by code that
> resides in the database itself, close to the data. I once had a
There is a balance: ETL and reporting code is often iterative
and can be more flexable in an external la
On Sat, 28 Apr 2018 08:02:21 +0200
"Peter J. Holzer" wrote:
> On 2018-04-27 22:52:39 +, g...@luxsci.net wrote:
> > Perhaps I'm extreme. In my ideal world, developers might not even
> > know table names! I'm kidding ,sorta...
>
> If they don't know the table names, how can they write those
11 matches
Mail list logo
