IssueTracker

As a corollary, for properties where unique=True one
should be able to fetch an entity by doing
Model.get_by_uniquepropertyname and also
Model.get_or_insert_by_uniquepropertyname... like Rails does with
ActiveRecord (e.g., Book.find_or_create_by_isbn).

I'd rather see this added as an index feature, so the uniqueness could be spread
across multiple fields (and an index would almost certainly be needed to support this
efficiently, anyway).

I totally agree that this should be implemented as an index. It could (and I think
should) still be specified in the schema/property constructor and the index
automatically generated.

It would also be great to have a way, in the schema declarations, to specify
composite unique indexes/properties, especially for reference properties.

Yes, this would be super useful.

Yes, this is a very common usecase +1

I need this feature.

Can't this be done with a carefully contstructed key name?

No. It can't be done with a carefully constructed key name... because the key name is
immutable once it is set at creation. For example, say you have a User model with an
email address in it. You want the email address to be unique across all User
entities. If you use the email address as key name you are out of luck when the user
changes his/her email.

no i don't think so, because keys are used to reference objects, so if you change the
key you have to update all referencing properties.

uniqueness is not the same use-case as a primary key

hi all! we've discussed this a bit internally, and we agree, it would be a useful
feature. it's definitely one of the most widely used constraints in SQL schemas.

unfortunately, it would be pretty difficult to implement with the current datastore
architecture, due in large part to our index consistency model, described in
http://code.google.com/appengine/articles/transaction_isolation.html . we might have
to chalk this up as another place the datastore doesn't provide traditional
relational database features.

at first, the key_name approach seemed tempting to me too. unfortunately, as edoardo
and bernddorn mention, it effectively makes those properties read only. having said
that, i suspect that "unique" properties like these actually are often read only, so
that might not be quite as big a drawback.

out of curiosity, would this feature be useful to anyone if it was limited to entity
groups? ie, you could specify that property values must be unique within each
individual entity group, but they could be repeated across entity groups?

ryanb: even properties that are thought to be immutable/readonly (like unique
identifiers, say ISSN/ISBN etc) may actually change in the future (and they did).
That is why, in general, it is a very bad idea to use properties as key_names (that's
the all thinking behind using a simple integer as primary key in relational database
design). Moreover, there are unique properties (say email addresses) that you want
unique and are most likely to change.

The correct way of implementing this would be to have the unique constraint apply
within all entities of a specific KIND, not just an entity group as you suggested.

Another way of going at it would be to be able to query the datastore within a
transaction.

for me this would be totally ok, afaik an entity-group is needed anyways to check
uniqueness in a transaction safe manner, isnt it?

even though in my applications i do not check uniqueness transaction safe. i thought
that if this would happen on the datastore end it would be possible implement it on
the storage/index level, which would make it much less error prune than doing it on
the application level via properties.

Transaction isn't needed to guarantee a property is unique. Do a put and followed by
a query on that property, if count is greater than 1, delete self. If you worry about  
exception, you can mark one property of the new object to indicate it's new and flip
it once verified unique. If there's contention of put, both object should delete them
self, there shouldn't be 2 object both marked old but with same property value.

Of course solve this on index level is much efficient.

question: Are entity ID's guaranteed to be unique?

If so, would it be possible to create a property that does something like:

entity.index = eventual_id

instead of:

entity.put()
entity.index = entity.key().id()

[Comment deleted]

generally, no, IDs are not unique. however, they will be unique for entities with the
same kind and the same parent, or root entities of the same kind.

in general, the full path is the only thing that's always guaranteed to be unique.
see
http://code.google.com/appengine/docs/datastore/keysandentitygroups.html#Paths_and_Key_Uniqueness
.

I think this "compromise" is pretty much useless. The whole point of having unique
entities is to have some slightly more complex guarantees about consistency than what
you currently provide with key_name. Is this feature really impossible to implement
in a scalable way or is this a specific problem of bigtable or the datastore?

What about allowing to safely change the key_name? Could you somehow allow for
locking two entity groups at the same time? If a deadlock occurs you could just
revert one of the transactions and let the other continue to run. This might need
some more thought though. :)

I ran into this and between a thread in the groups and this ticket, it's been
helpful. I did come up with a solution for my specific use case. I'm using a floating
point number as a score and need it to be unique because I am paging off of the
value. I also needed it to not be immutable, because scores can change. What I did
was override the put method, with a check to confirm the value being unique and if
not, then adjusted it and tried again.

    def put(object):
        valid = False
        while valid == False:
            cquery = db.GqlQuery('SELECT * FROM Story WHERE score = :1', object.score)
            results = cquery.fetch(1)
            if len(results) > 0:
                value = value + .01
            else:
                valid = True
        super(Story, Story).put(object)

One thing that might be useful from the appengine standpoint would be to add an
attribute similar to validator for properties, like unique_validator = None, which
could then be a hook for developers to create their own functions. Or if you needed a
more generic function that could raise an exception, it could be something similar to
the above, except it would raise an exception on the check for an existing value, and
it could then be up to the developer to catch the exception and adjust the value
accordingly before reattempting the put operation. Then you could just have a unique
= True/False attribute.

In JPA (Java) there is an annotation @UniqueConstraint [1] that can be put on the
class-level table annotation to identify which properties should be unique (either
alone or alongside others). This is usually used in addition to property-level
annotations, which have that unique=True/False property.

Before calling put(), the information from the annotation (or a simple property
_unique_constraints) is used to issue some queries, and, if no constraints are
violated, the entity is stored. If any constraint is violated an appropriate error
can be raised.

I have implemented a very basic version of my suggestion, which is enough for what I
need:

## start

class DbEntity(db.Model):
  _unique_properties = None
  timestamp = db.DateTimeProperty(auto_now=True)
 
  def __init__(self, parent=None, key_name=None, _app=None, unique_properties = None,
**kwds):
    super(DbEntity, self).__init__(parent, key_name, _app, **kwds)
    if unique_properties:
      logging.debug("Unique properties: %s" % unique_properties)
      self._unique_properties = unique_properties
 
  def put(self):
    if self._unique_properties:
      logging.debug('checking unique properties for : %s ...' % self.__class__)
      for unique in self._unique_properties:
        gqlString = 'WHERE %s = :1' % unique
          param = eval('self.%s' % unique)
          logging.info('GQL: self.gql("%s", %s)' % (gqlString, param))
          query = self.gql(gqlString, eval('self.%s' % unique))
          otherObjects = query.fetch(10)
          if len(otherObjects) > 0:
          logging.error("Objects that violate the constraints: %s" % otherObjects)
          raise db.BadPropertyError("Other instances of %s exist with %s = %s" %
(self.__class__, unique, param))
    return super(DbEntity, self).put()
               
class Team(DbEntity):
  name = db.StringProperty(required=True)
       
  def __init__(self, parent=None, key_name=None, _app=None, **kwds):
    # set the unique property names
    super(Team, self).__init__(unique_properties = ['name'], **kwds)

## end

[1] http://java.sun.com/javaee/5/docs/api/javax/persistence/UniqueConstraint.html

re: Comment 23

This code contains a race condition and will not ensure uniqueness (it should, most
of the time, but there's no uniqueness guarantee).

sorry my bad english but ehy me get 2 insert when me wait 1

This is a total kludge but what if you did memcache.add("dblock", "dblock", 10), then do a query to see if there are any existing objects in the datastore with your unique fields before doing the db.put() and then memcache.delete("dblock").  If the memcache.add() returns false, just wait a random number of milliseconds and try again.

Yes, unique constraints are critical to certain use cases.  My problem is that I allow the datastore to create unique, immutable numeric IDs for the Key, which are used for entity relationships, but I need mutable secondary key for human readable keys that may change.  I ran into a case where a request was repeated quickly (within 50ms) and so two JVMs handled them simultaneously.  Within a transaction, the code queried on the secondary key to see if it already existed.  Both handlers got null, since the entity did not yet exist.  They then created it and the datastore assigned two unique numeric primary keys to the new entities.  This left me with two entities with duplicate secondary keys.

I understand there is a technique that involves creating an auxiliary entity to be used as a mutex for the secondary key.  In JDO/JPA that is a bunch of ugly, obfuscating code that requires extra java classes, etc.  JDO/JPA pretty much assume the semantics of a full SQL datastore, so this kind of kludge really shows that JDO/JPA is not a great solution for the Google datastore.  The technique is much less offensive if you are using the low level api.  But, all my code now uses JDO, so it it possible to implement the uniqueness annotation?

From my point of view, it would be OK to require an index and/or assume that writes to such entities would take longer.  I understand that the stage 1 (commit phase) of write does not update indices, so that (as it now stands), the entity is effectively committed (logged and visible to get()) prior to any indices being updated.  Indices are updated in phase 2, which can occur after the commit call returns.  However, uniqueness constraints are very important, so much so that it would be OK with me that my commit waited for phase2 to finish before it returned.  This would allow the indexing phase to enforce the uniqueness constraint.  It would also be ok that the non-unique entity committed in phase 1 is visible to get() until phase2 rolls it back.

At at the very least, having a uniqueness constraint that only allows ONE of the entities into the index might be good enough.  In other words, if I query by secondary key, I will get a single entity and it will always be the same one.  

An obvious case where you want uniqueness is with user logins. My app uses email addresses for the login. We set the key_name of our account model and use get_or_insert() to effect uniqueness.

The downfall is when the user wants to change their email address. We have to clone not just their account entity, but all the entities underneath it (of which there are potentially many thousands.) Of course, we want the user to be able to use their account during this time, so there's a lot of logic that pains me to have to keep around just to deal with the case of accounts in motion...

is there a suitable work around for java to ensure uniqueness of a property in the datamodel?

We've used this technique on a number of our applications: http://squeeville.com/2009/01/30/add-a-unique-constraint-to-google-app-engine/

It's simple but has some possibility of leaving unique values unable to be used, though it will guarantee that a unique value is actually unique. That is, because there is no transaction between the Unique model and the model holding the unique values, a failure might cause a unique value to be used. It fails on the side of guaranteeing uniqueness.

The example is Python, but is simple enough that there will be a direct Java analogy.

you can also combine the technique in #30 with cross group transactions. this will protect you against losing unique values.

you create an entity group for each unique field. and then do a cross group transaction on checking/updating that entity group along with the entity group of your model.

this limits you to 4 unique fields per model, and is probably terrible for performance since you're effectively serializing writes across each field. but if you really really need uniqueness...

After investigating a bit about this problem, I got two possible working solutions, that could be implemented at the application level:

@ndb.transactional
def put(self):
  from google.appengine.ext.db import STRONG_CONSISTENCY
  key = User.gql("WHERE ANCESTOR IS :1 AND email = :2", self.key.parent(), self.url).get(keys_only=True, read_policy=STRONG_CONSISTENCY)
  assert key is None or key == self.key
  ndb.Model.put(self)

def put(self):
  from google.appengine.api import memcache
  memcache_key = "UserEmail" + repr (self.url)
  assert memcache.incr (memcache_key) is None
  try:
    from google.appengine.ext.db import STRONG_CONSISTENCY
    key = User.gql("WHERE ANCESTOR IS :1 AND email = :2", self.key.parent(), self.url).get(keys_only=True, read_policy=STRONG_CONSISTENCY)
    assert key is None or key == self.key
    ndb.Model.put(self)
  finally:
    memcache.delete(memcache_key)

Of course I prefer the first one, and according to the documentation both should work.
Yet some people insist on the using memcache to ensure there are no race conditions.

The only reasoning I see is because of the query, but even so, in the same entity group, transaction are serializable according to the documentation, so it should work just fine. What am I missing?

Just wanted to bump this issue a little bit. In Djangae (https://github.com/potatolondon/djangae/) we've implemented a kind of unique constraint support by creating marker instances for a unique combination. The key of the marker is constructed from the unique combination (enforcing uniqueness) and markers are acquired (in independent transactions) before a Put() and released after a Delete().

Markers also have a creation time, and an associated instance. If a marker for a unique combination already exists, then we check to see if its associated instance still exists (by doing an Ancestor, keys_only query on its key) before raising exception.

When creating new instances (where the Key id hasn't yet been generated) then we create a marker without an associated instance key, but we ignore such markers for unique constraint checking after a few seconds.

Obviously, this is a bit of a kludge, but it seems to work, and we've tried the approach on some pretty high traffic sites - it is costly though, both in performance and quota, but sometimes you really need to enforce uniqueness.

It would be much better if a similar approach could be implemented in the datastore itself. This is still a very sought after feature.

Bump.

I believe this is quite an important feature to be implemented.
I have run into similar constraints without it.

Upvote + 1

We need this!

@Google, come one! This has been a known issue since 2008. Get this solved and ensure that firebase/firestore is competitive with other like database products.

much awaited feature.

Is there any good method available to get this working

wow. I commented on this issue over a decade ago. I don't think there's a good fix, but now you can use Google Cloud SQL instead, and set unique=true in your table schema...

Are we getting this? Ever?

Why is this infeasible? PostgreSQL is enabled as a data source for DataStudio. Why not just fully implement jdbc?

please, please support postgresql!!

guys, i hate to say it, but since I posted this request in 2011 there has been zero progress.

never. gonna. happen.

Google Cloud SQL Postgresql is in Beta right now. It makes sense to support postgresql driver through JDBC,
Thanks,

yes, we need support for Postgress sql in Google script

Please Google..

On 2 August 2017 at 13:51, <buganizer-system@google.com> wrote:

Replying to this email means your email address will be shared with the
> team that works on this product.
>
>
There's a team that works on this product?!

Please see the history above; we decided that we will not implement this feature in Apps Script.

hahaha yes but will you implement postgresql driver through jdbc???

this has been dead a long while folks

On Wed, Aug 2, 2017 at 12:24 PM, <buganizer-system@google.com> wrote:

Well, it's a shame. Here we started to use https://datastudio.google.com/ , and PostgreSQL support works fine. It's still in development, but I bet that will be very powerful in the future.

You can connect Postgresql to Google sheets with the SuperMetrics addon, only free for 30 days though.

So has this become feasible in the past two years.   Would have thought the brilliant minds at Google would have figured this one out.

Not able to appreciate why Google decided not to implement PostgreSQL support in JDBC Apps Script when Google Data Studio supports it and Google Cloud Platform offers PostgreSQL as a database service.

Google, are you saying that the customers who chose Postgre from Google Cloud Platform cannot have their Google Apps Script connect to it? This is disgrace. Google, could you please review your decision in line with your support to Postgre SQL from your other product lines like Data Studio and GCP.

For me, it is a must for Apps Script to establish the connection with PostgreSQL. In fact, it is JDBC, it should support connecting to any database (DB2, etc) given we load the right JDBC driver.

Google, expecting more from you, thanks

No postgres support still? Despite postgres being an offering of Googles cloud platform?  This is insane!

On 7 Mar. 2018 18:35, <buganizer-system@google.com> wrote:

Replying to this email means your email address will be shared with the
team that works on this product.

https://issuetracker.google.com/issues/36752790

*Changed*

*jo...@conxjobs.com <jo...@conxjobs.com> added comment #55
<https://issuetracker.google.com/issues/36752790#comment55>:*
No postgres support still? Despite postgres being an offering of Googles
cloud platform?  This is insane!


I see you've encountered Google's attitude to their fodder.

The sooner you realise that they are not an enterprise-grade offering, you
can either knuckle down and dance entirely to their tune, or go find a
solution that actually suits your needs.

Sorry to break it to you,
David.

Google please add support for Postgres through JDBC. Why are you complicating a very simple process.

Google please add support for postgres through JDBC. I just want to automate my reports instead of spending hours every week pulling and exporting data :(

How can an API layer be added to Google SQL?  postgreSQL is a supported, GA platform for Google SQL.

In 2011, I am not surprised that this was infeasible, however now that postgreSQL is supported within Google SQL, I hope that some changes can be made.

Is someone from Google listening?

On Thu, May 24, 2018 at 8:32 PM, <buganizer-system@google.com> wrote:

--
thanks and regards
Michaes
_______________________________
Jivrus Technologies (www.jivrus.com)

I'm still listening :-) I raised this request with the Apps Script team again in December, but it was still out of scope. If we could enable connecting only to Google Cloud SQL PostreSQL databases, not arbitrary ones, would that be enough for most folks?

That would be at least consistent with what Google is offering, and would make me personally happy.  

Thanks ek...@google.com!

I would need to be able to access PgSQL on arbitrary addresses. It would be ok to limit it only to newest versions if that makes it easier somehow.

It would be strange to have full MySQL support but PostgreSQL limited to Google Cloud only.

Note that Google Data Studio also supports PostgreSQL as a datasource.

ek...@google.com,

Thanks for re-opening!

To specifically answer the question: yes -- if you could enable connecting only to Google Cloud SQL PostreSQL databases that would be enough for my team.

- Tim

p.s. On the hope (...no clue as to the reality...) that the following suggestion might be more feasible to implement than another JDBC-driver-like implementation, I do wonder if it might be worth considering a new Apps Script interface for PostgreSQL, closer to that provided by https://node-postgres.com/api/client. I'd personally prefer that for a number of reasons, although certain JDBC is acceptable. Apology in advance if this opens a can of worms.

GCP has Postgre as GA and Data Studio has a connector to Postgre. So Google
already has a way of connecting to Postgre. Moreover, App Script uses JDBC
(I guess it is a facade over Java being behind)  and there is no dearth of
drivers in Java to connect to Postgre.

I see the implementation (or non-implementation) is more strategic than
technical known only to Google.

There are times I have moved away from Apps Script as the existing database
was in Postgres.

I believe Google will eventually implement Postgre support in Apps Script,
the sooner is better for all.

thanks
Michaes

On Fri, May 25, 2018 at 10:44 PM, <buganizer-system@google.com> wrote:

--
thanks and regards
Michaes
_______________________________
Jivrus Technologies (www.jivrus.com)

Please consider supporting this. PostgreSQL is used everywhere in my org, and I'd love to use it from Google Apps Script. And yes, initially, it'd be fine to just support Google Cloud SQL PostreSQL...at least in my case. However, would love to see full support in the future.

Thanks!

In my case, my organisation's PostgreSQL is hosted in AWS so I would be very much interested in full support of any PostgreSQL DB.

it's been like 7 years google cmon. It shouldn't be that hard for you guys

Google has to want to do this. Clearly they do not.

On Mon, Oct 22, 2018, 4:49 AM , <buganizer-system@google.com> wrote:

wow seems that this is not an option, how can they have mysql before postgres?
some internal business that did not go well xD

Google needs to get with the times. PostgreSQL is now the standard for a lot of enterprise applications running on AWS. There is little incentive in using any of Google's products if we can't use Apps Script to connect to PostgreSQL

any update on this?

Sorry, no updates at this time.

Eight years guys. Having postgres support at the very least within Cloud would be really helpful.

wow, I have just made a business case to get a postgres instance on Google Cloud Sql to just find out that I cannot make a application using Google Script to interact with this service? Is this even real? am I missing something?

Could anyone point me in the right direction to make a connection to Cloud Sql Postgres instance via Google Scripts? PLEASE I need HELP Quick!!!

Perhaps sheets + postgresql? https://zapier.com/apps/google-sheets/integrations/postgresql

But yeah, it's ridiculous.. google's ecosystem isn't user friendly at all.

@mr...@gmail.com
thanks, but that is not what I`m really looking for.

Google have really let themselves and their users down on this issue!

I would appreciate if someone please could confirm if thats really the case that there is no way to directly make a connection/interact between Google Cloud Sql Postgres Instance and Google Scripts services?

I will have to re-design my project in a huge way if the answer to my question is YES (Unfortunately)

Many thanks in advance!

Perhaps describe what you're looking to achieve in case there are alternatives. I've come across this problem before and looks like there's no direct way to communicate between postgresql & google scripts.

I was tasked to re-write google script (web app) which ironically happened because one of the google service is being completely switched off in few months time. Current application is using a lot of spreadsheets as a back end so my first thought was to move it to proper DB, after a proper research I got an impression that for this, really need a Cloud SQL (relational database) even thought business seems to got stuck on BigQuery (BigTime - I mean for everything!), taking under consideration the fact that I hit the wall (very disappointed with google) need to consider: BigQuery as a back end or MySql instance in Cloud Sql.

I am extremely disappointed in google and dont really understand how company of this size can afford to propose a service without basic integration with other services especially comparing it to MySql instance (double standards?)

Thank you all for your input on this matter.

Hi All,

Unfortunately, there is NO support from connecting the PostgreSQL database from Google Apps Script (though Data Studio can connect to PostgreSQL). I would be extremely happy if someone proves this wrong. Reason being - many of our customers  (and ourselves) wanted a way to directly pull data from databases into Google Sheets. We built the Database Browser add-on product (https://databasebrowser.jivrus.com/) with a mission to query/ edit any database from Google Sheets. We succeeded to maximum level interfacing with MySQL, GCloud SQL, Oracle, MS SQL Server, BigQuery, Firestore etc except PostgreSQL. We have been following this issue (raised in 2011). But no solution yet.

Clearly, if Data Studio can connect to PostgreSQL, then Apps Script should be able to connect, but it is NOT.  Google just does not want this feature to be available to Apps Script for unknown political reason (there is nothing technical here AFAIK).

Google, we like your products; the stranded customers who have chosen G Suite and PostgreSQL will also like you EVEN MORE if you let Apps Script connect to PostgreSQL directly. Hope you would do that soon.

cheers
Michaes
https://www.jivrus.com

This deserves a response from Google for no other reason than the Cloud SQL for PostgreSQL FAQ (https://cloud.google.com/sql/docs/postgres/faq) EXPLICITLY states that accessing Cloud SQL PostgreSQL IS possible using JDBC.

Q: Can I access my Cloud SQL instance programmatically outside of App Engine?
A: Yes. You can access Cloud SQL instances programmatically from external applications using any supported language. You can also connect using JDBC, including writing Apps Script scripts to access your Cloud SQL databases.

To reiterate: ...including Apps Script...

Google? Can you PLEASE confirm or deny that this is possible? Is the FAQ correct or incorrect?

jeez...they have done nothing about this since i first started this request
in 2011. considering their response for the past eight years, i think you
have your answer.

On Sun, Mar 10, 2019 at 11:25 PM <buganizer-system@google.com> wrote:

@Tim York - I (Googler) have responded to this issue before, but always with the unfortunate news that there hasn't been progress. Good catch on that documentation though, it is completely wrong. It looks like it was copied from the corresponding MySQL docs (https://cloud.google.com/sql/docs/mysql/faq#externaldev) and wasn't updated. I'll raise that with the team to get it corrected.

Thanks anyway for the response. Unfortunately, catching the documentation error sent me down a 2-day path that is now completely worthless.

Can you at least say whether it's something that is being worked on or exists somewhere on a roadmap? No dates needed. It would just be nice to know you guys recognize it a serious functionality gap that needs closure. You're giving Microsoft way too much time to catch up.

Would https://github.com/PostgREST/postgrest work for you? Since google recommends an api layer for now

I'll check it out. Thanks for the suggestion!

@Tim York, adding PostgreSQL support is not being actively worked on nor is it on a roadmap.

- When using Google Data Studio it is possible to connect to a postgres database, but not SQL Server.
- With Apps Script, it is possible to connect to a SQL Server database, but not postgres.

This is a little frustrating & makes it difficult to choose a database that will interact well with Google products.

It's very frustrating dealing with some of google's services, they definitely don't make it easy to use, from google home to google apis. Too many PhDs are not great with usability it seems. They're also acquiring companies/projects(BigQuery) that goes against the interest of pursuing widely accepted DBMS such as postgresql. They're allocating resources where they feel they can earn most while ignoring foundational features.

It's like they've acquired NEST and not really focusing energy to provide support for ECO Bee (Superior product) for their google home.. at least in a timely fashion. They need a more democratic approach to these things.

This is a simple ask from PostgreSQL users for the last 9 years. NINE YEARS!!! come on Google!!!

9 years and nothing... :(

Sad, Still nothing!!

Come on google, sort it out. Shouldn't be rocket science and has been in the works for what.. 9 years?

Heaps of people use postgres. We wanna connect it to awesome google sheets. Throw us a bone!

+ 1

I'm also super surprised there's no postgres integration. +1 for this feature.

+1

Google team please add support for Postgres to JDBC, it is extremely lame that action on this hasn't been taken even when so many developers require it. Please take this up in priority. Postgres has become a standard now.

+1000

yes, this should be supported and easy

if there is a plan to support it, can a timeframe be publicized please ...

+1

On Thu, Oct 17, 2019 at 8:52 AM <buganizer-system@google.com> wrote:

+1000

+10000000000

+1

+1

+1

plz!

+1

come on google.

+1

+1

+1

+1

+1

+1

I'll throw my name in the hat for this one.  +1

+1

+1

+1 please!!

+1 come on, guys.....

+1

+10000000

+1

+1

+1

+1

+1

How many times do we need to ask for this quite simple thing to do (I guess no more than driver compilation on the java wrapper) ?

When will it available this option?
I need this option
+1

+1. This is insane that this isn't possible.

Perhaps better to move to a more supportive infrastructure provider?

+1

+1

+1

+1

+1

+ 10000 !

+1

Still nothing here? Is a bit weird...

+1

+1

+1

Fixing this issue would facilitate a lot of good work! +1

+1

+1

PLEASE GOOGLE!!! it's been 9 years ;(

+0

+1

+1

+1

After waiting for a long time for our add-on Database Browser, we ended up developing a private interface through Google Cloud Platform to connect with PostgreSQL, the latest version of MySQL, MongoDB, DynamoDB etc in our Database Browser add-on to pull/push data to Google Sheets.

Could have been easier if Apps Script supported this natively

Please make it possible, which could be the reason to not support Postgresql JBDC connection? I would be very useful, just the same way there is mysql JBDC connection...

10 years from the first request, and still nothing at all :(

+1

+1

+1

Wow, I can't believe it's been 10 years for such a small feature and still no sign of update from Google. Shame.

it's been 10 years, and still no matter.
+1 PLEASE

+1

+1!!!

+1 !!!!! up!!

+1 Come on, this can't be that difficult

+1

This is horrible, an issue lasting for 10 years and ignored.