As Jan mentioned in his thread about a pluggable wire protocol [0], AWS is
working on a set of extensions for Babelfish. The intention is to not
necessarily have it as a single monolithic extension, but be possible for
people to use pieces of it as they need when they are migrating to
PostgreSQL. S
On Mon, Feb 22, 2021 at 3:52 PM Andres Freund wrote:
> Hi,
>
> On 2021-02-22 11:20:54 -0500, Jim Mlodgenski wrote:
> > As Jan mentioned in his thread about a pluggable wire protocol [0], AWS
> is
> > working on a set of extensions for Babelfish. The intention is to not
&g
On Mon, Mar 15, 2021 at 12:43 PM Julien Rouhaud wrote:
> On Mon, Mar 15, 2021 at 11:48:58AM -0400, Jim Mlodgenski wrote:
> >
> > Going deeper on this, I created another POC as an example. Yes, having a
> > hook at the top of the parser does mean an extension needs to
On Mon, Mar 15, 2021 at 12:58 PM Joel Jacobson wrote:
> On Mon, Mar 15, 2021, at 16:48, Jim Mlodgenski wrote:
>
> The example I have is adding a CREATE JOB command that a scheduler may
> use.
>
>
> This CREATE JOB thing sounds interesting.
>
> Are you working on add
On Thu, Feb 11, 2021 at 10:29 AM Andrew Dunstan wrote:
>
> On 2/11/21 10:06 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Thu, Feb 11, 2021 at 9:42 AM Jonah H. Harris
> wrote:
> >>> As Jan said in his last email, they're not proposing all the different
> >>> aspects needed. In fact, nothi
On Mon, May 1, 2023 at 9:29 PM Thomas Munro wrote:
>
> I am not aware of any modern/non-historic filesystem[2] that can't do
> large files with ease. Anyone know of anything to worry about on that
> front?
There is some trouble in the ambiguity of what we mean by "modern" and
"large files". Th
On Thu, May 11, 2023 at 7:38 PM Thomas Munro wrote:
> On Fri, May 12, 2023 at 8:16 AM Jim Mlodgenski wrote:
> > On Mon, May 1, 2023 at 9:29 PM Thomas Munro
> wrote:
> >> I am not aware of any modern/non-historic filesystem[2] that can't do
> >> large files
On Fri, Feb 4, 2022 at 5:12 PM Tom Lane wrote:
>
> On the whole I'm kind of allergic to inventing an entire new concept
> that has as much overlap with extensions as modules seem to. I'd
> rather try to understand what functional requirements we're missing
> and see if we can add them to extensi
On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule
wrote:
>
> The main issue in this case is fact, so plpgsql is fully integrated to
> Postgres (on second hand this integration is a big performance win). It is
> pretty different from PL/SQL. In Oracle you have a package, or any other
> similar featur
Working with users over the years, some have large libraries of server
side code sometimes consisting of 100k+ lines of code over 1000+ functions
and procedures. This usually comes from a migration of a commercial
database like Oracle where it was best practice to put all of your
business logic int
On Wed, Jun 2, 2021 at 9:58 AM Tom Lane wrote:
>
> In the first place, what do you think the primary key of pg_namespace is now?
In the patch the unique constraint is (nspname, nspnamespace) which is
certainly awkward. I initially went down the pg_module route to avoid
adding another catalog, but
On Thu, Jun 3, 2021 at 8:49 AM Peter Eisentraut
wrote:
> Given that, as you said, the concept of modules is in the SQL standard,
> there is surely some guidance in there about how this is supposed to
> affect name resolution. So let's start with that. Maybe we won't like
> it in the end or whate
On Sat, Jun 12, 2021 at 4:29 AM Julien Rouhaud wrote:
> I'd like to propose an alternative approach, which is to allow multiple
> parsers
> to coexist, and let third-party parsers optionally fallback on the core
> parsers. I'm sending this now as a follow-up of [1] and to avoid duplicated
> eff
On Wed, Jul 7, 2021 at 5:26 AM Julien Rouhaud wrote:
>
> Also, if this patch is eventually committed and having some code to
> experience the hook is wanted it would probably be better to have a
> very naive parser (based on a few strcmp() calls or something like
> that) to validate the behavior r
On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs
wrote:
>
> The general rule has always been that we don't just put hooks in, we
> always require an in-core use for those hooks. I was reminded of that
> myself recently.
>
That's not historically what has happened. There are several hooks with
no in cor
15 matches
Mail list logo
